Emulator

I can confirm I'm seeing the same thing on a M1 MacBook Air. Worked great on Big Sur. Does not work on Monterey 12.0.1. Nothing seems relevant in the Console.app logs, but I'm not sure what to look for other than 'Dolphin' and 'Bluetooth'. I also went through the pairing guide (https://dolphin-emu.org/docs/guides/wii-remote-plus-rvl-cnt-01-tr-connection-guide/) with no success.

I do Mac development so I could potentially help here, if anyone has any idea where to start looking.

I was really looking forward to cranking the settings like crazy when my 14" M1 Max gets here next week :)

This issue really needs more attention! I literally just got a Wiimote to use with Dolphin, only for it to not be able to work >:((((

I've never tried to sync a Wiimote before Monterey, so I don't know about macOS rejecting previously-connected Wiimotes. However, while I was trying to pair my Wiimote, I noticed that there's a lot that's different in Monterey's Bluetooth settings that contradicts the pairing guide:

• When you press the Wiimote's sync button inside the battery cover, macOS will automatically pick it up. First it will show the MAC address, then it will show the actual device name after a while.
• When you click "Connect", pairing will not fail. Instead, macOS will try to make you input a 4-digit code that you can't even see. I can't find a way to use some other method, like a regular passcode. I'm guessing this is some stupid security feature they added.
• Guides online will say to input a code like "0000" or "1234". Neither of these codes work, at least not with my Wiimote. Even entering an ASCII string with the backwards MAC address just causes the Bluetooth settings to say "Passkey mismatch".
• Speaking of the MAC address, right-clicking on an item in the Bluetooth list does absolutely nothing. I have to memorize my Wiimote's MAC address now.
• After getting the password error, I did temporarily see an "Options..." button next to the device name in the list. However, clicking on that just asks me to enter the 4-digit code again.

I'm also on macOS Monterey 12.0.1. After many minutes of trying to sync my Wiimote, the settings showed me it's a "Nintendo RVL-CNT-01".

I've done some research into this and have gotten nowhere too.

My Wiimote used to work with my Mac on Monterey, until I removed my existing pairing to test pairing from scratch specifically for this issue. (I paired it while I was on Big Sur.)

The guide on the website / wiki appears to be really outdated. The "Passcode Options" button no longer exists since at the very least macOS Sierra.

I wrote a tiny program to try pairing the Wiimote programmatically (https://github.com/OatmealDome/WiimotePair/), and got nowhere with it. The Bluetooth APIs appear to not function correctly (the pairing start callback isn't called for some reason? perhaps I'm doing something wrong) and pairing eventually fails with an IOKit general error, which isn't very helpful.

The last thing that appears in Console.app that appears to be relevant is this message:

peerDidRequestPairing: User has not previously provided a PINCode for device type 26 & the peer '<CBClassicPeer: , Nintendo RVL-CNT-01-TR, disconnected, Unpaired, , devType: 26, PID: 0x0330, VID: 0x057E>' that has no input capability. Displaying pairing options now.

Specs:
MacBook Pro (2019)
macOS Monterey 12.0.1

It seems like not only are lots of people having issues with Wiimotes on Monterey, but Bluetooth in general. There are tech news reports saying something like "Monterey's Bluetooth core has been reworked, so tons of Bluetooth devices have stopped working".

I wonder if that's what's going on here? In that case, we'd have to wait until the end of the month for Monterey 12.1 to see if it's fixed.

sigh.... I updated to Monterey 12.1, and it still doesn't work DDD:

I just bought 4 Wii remotes & a sensor bar as a Christmas gift for the family - only to discover that the remotes don’t work with our M1 MacBook Pro 😩🤬

Judging by the lack of response & resolution on this thread, it’s sounding like I may have wasted our money. Definitely wouldn’t have done that, had I known about this issue.

OK, so I tested my Wiimote and Sensor Bar on our Windows PC, with Dolphin's latest dev version and continuous scanning on, and the Wiimote works just fine. So this isn't a Dolphin problem, it's a macOS problem. I sent a report on Apple Feedback, but for now the waiting game continues. (Maybe if more people submit feedback to Apple, the issue could get fixed sooner? 🤷🏽‍♂️)

Having the exact same issue on an M1 Mac running Monterey 12.1
Quite disappointed that I can't fix this on my own. I don't understand how this hasn't gotten more attention, I feel like Mac users wanting to connect Wiimotes would be a sizable share of the userbase.

This issue is getting a lot of attention. It's just that nobody has any idea what could be done to fix it. I mean, at this point we don't even know if it's possible to fix the problem on our side at all.

😮‍💨...still doesn't work in Monterey 12.2. At this point, I won't keep repeating the same thing over and over again. I'll just post when Wiimotes finally WORK.

In the meantime, I feel like the best thing to do would be to bombard Apple with macOS feedback. This definitely isn't a Dolphin problem if macOS refuses to connect Wiimotes in the first place, so I think we should garner more attention on Apple's side to fix this issue once and for all. Maybe news articles even, I haven't seen any of those 😤

I plan to submit a Technical Support Incident to Apple in cooperation with Slippi's macOS maintainer (rymc) at some point. This will get an Apple engineer to look at the issue, but it might be a while still before the issue is resolved.

I did not know that existed, it does sound like it will be more effective :D

Hi all!

So I also ran into this issue. I recently purchased a new 16" 2021 MBP, which is only supported in Monterey, so no downgrading for me.

After looking into the issue, I purchased a DolphinBar on Amazon (using the affiliate link to support the project) and it worked instantaneously for me (Dolphin 5.0-16007). It provides a bunch of extra functionality that I've never been able to use in Dolphin before, so I'll happily continue to use it, even if it means that I have to carry another item with me.

nhubbard wrote:

After looking into the issue, I purchased a DolphinBar on Amazon (using the affiliate link to support the project) and it worked instantaneously for me (Dolphin 5.0-16007). It provides a bunch of extra functionality that I've never been able to use in Dolphin before, so I'll happily continue to use it, even if it means that I have to carry another item with me.

Well, seems like we have a solution! However, there is still an issue with the operating system if it can't directly support Wiimotes, but this seems like a good workaround.

nhubbard wrote:

Hi all!

So I also ran into this issue. I recently purchased a new 16" 2021 MBP, which is only supported in Monterey, so no downgrading for me.

After looking into the issue, I purchased a DolphinBar on Amazon (using the affiliate link to support the project) and it worked instantaneously for me (Dolphin 5.0-16007). It provides a bunch of extra functionality that I've never been able to use in Dolphin before, so I'll happily continue to use it, even if it means that I have to carry another item with me.

Thanks for this reply! I can't connect Wiimotes to my Mac directly, but DolphinBar worked perfectly. Wanted to chime in here because I saw a lot of posts scattered around that said DolphinBar wouldn't work in MacOS. M1 Max, Monterey 12.2, Dolphin 5.0-15445.

Following up on OatmealDome's pairing program, I pulled up IOBluetooth in Ghidra. For anyone else looking to do this, searching for console strings in the binary is a very good way to find the code that printed that console log.

[IOBluetoothDevicePair peerDidRequestPairing:type:passkey:] contains (approximately) the following code:

if (type == 6) {
	id adapter = [IOBluetoothDeviceCBPeerAdapter deviceFromClassicPeer:peer];
	os_log("peerDidRequestPairing: Pincode Pairing. Pincode received: %@", [passkey unsignedIntegerValue]);
	if ([self userDefinedPincode]) {
		os_log("%s: User-defined Passcode found.", "-[IOBluetoothDevicePair _peerDidRequestPairing:type:passkey:]");
		[self pinCodeRequest:adapter];
	} else {
		if (some other stuff) {
			some other stuff
		} else {
			os_log("peerDidRequestPairing: User has not previously provided a PINCode for device type %d & the peer \'%@\' that has no input capability. Displaying pairing options now.", [peer deviceType], peer);
			[self devicePairingFinished:adapter error:0xe00002bc];
		}
	}
}

...pinCodeRequest: calls devicePairingPINCodeRequest:, so it looks like it now only sends that if userDefinedPincode is true. Conveniently, they have getters and setters for that, so...

@interface IOBluetoothDevicePair()
- (void)setUserDefinedPincode:(BOOL)enabled;
@end

IOBluetoothDevicePair* doPair(IOBluetoothDevice* device, id<IOBluetoothDevicePairDelegate> delegate) {
	IOBluetoothDevicePair* pair = [IOBluetoothDevicePair pairWithDevice:device];
	[pair setUserDefinedPincode:YES];
	[pair setDelegate:delegate];
	[pair start];
}

and we get more fun logs, but no success:

IOBT -[IOBluetoothDevicePair _peerDidRequestPairing:type:passkey:]: User-defined Passcode found.
bluetoothd Sending 'pincode request' pairing event for device 40:D2:8A:B9:DA:F1
bluetoothd Received XPC message "CBClassicMsgIdPairingAgentRespondToPairing" from session "IOBT-555549440166398757ba342887c753e9932bab58-classic-99866-844"
bluetoothd handlePairingAgentRespondToPairing: Pincode (received as a number) 0 for the device "<private>"
bluetoothd handlePairingAgentRespondToPairing: Accepting Pairing Request with Pincode <private> for the device "<private>"
IOBT -[IOBluetoothCoreBluetoothCoordinator pairPeer:forType:withKey:] pair peer: <CBClassicPeer: 0x100e04080 774A203D-6851-EEA1-D597-C9FAE4044CA4, Nintendo RVL-CNT-01-UC, disconnected, Unpaired, 40:d2:8a:b9:da:f1, devType: 26, PID: 0x0330, VID: 0x057E> for type: 6 using key: 0
bluetoothd handlePairingAgentRespondToPairing: pincode being used is <private>
bluetoothd Setting pincode <private> for device 40:D2:8A:B9:DA:F1
bluetoothd Enforcement complete with STATUS 705
bluetoothd Policy enforcement failed STATUS 705 - cid 0x0000AC06, handle 32505856 securityFailed 1 (status=65535)
bluetoothd L2capControlConnectCfm: STATUS 705 (status=65535)
bluetoothd Connection to device 40:D2:8A:B9:DA:F1 failed - result was 705
bluetoothd Received connection result for "HID Host" profile on device 40:D2:8A:B9:DA:F1 - result was 158
bluetoothd Pairing failure reported for device 40:D2:8A:B9:DA:F1
bluetoothd Unblocking pairing for device 40:D2:8A:B9:DA:F1
bluetoothd Cancelling existing pairing timeout event
bluetoothd Pairing complete for device 40:D2:8A:B9:DA:F1
bluetoothd Device 40:D2:8A:B9:DA:F1 ClassicSMPSupported:0 encryptionMode:0
bluetoothd pairingComplete result:158 device->isDerivedFromLE:0 connectionSupportsClassicSMP:0 fCTKDDisabled:0 isPendingClassicSMP:0 address:<private>
bluetoothd Sending 'pairing complete' event for device 40:D2:8A:B9:DA:F1 with result 158
... lots of other messages as the failure makes its way back to the app

I checked the code that calculates the message for the "Enforcement complete with" message, and the error formatter returns "OI_STATUS_NONE" for 0xffff, which seems to match the header of this bluetooth library that's also used in Android: https://android.googlesource.com/platform/system/bt/+/8289925/embdrv/sbc/decoder/include/oi_status.h
If that is where this came from, 705 is OI_HCIERR_AUTHENTICATION_FAILURE, which I assume means we sent the wrong pin.

So let's look at what happens when we call replyPINCode:PINCode:...

• A number of checks are done on a subobject of IOBluetoothDevicePair, of class IOBluetoothDevicePairExpansion. This includes checks for isWiiRemote and isWiiUProController, both of which are false in this case, but I assume this is the code that made it so wiimotes would just pair with older versions of macOS without any special applications. I checked the IOBluetooth dylib from Mojave, and this code is unchanged from back then. If isWiiRemote or isWiiUProController is true, the correct key is calculated from the device address and used in place of the one supplied to replyPINCode:PINCode:.
• Diverging from the Mojave code (which sent the code straight off to the kernel at this point), it calls [[NSString alloc] initWithBytes:pincode length:8 encoding:NSUTF8Encoding]. Sure hope that pincode was no more than 8 bytes long and valid UTF-8...
• Then it calls [CBUtil preSSPStringToParingCode:string] which takes the string, converts it back to bytes, and memcpy's it in a 64-bit integer
• Then [NSNumber numberWithLongLong:integer], embedding it in an NSNumber
• It calls [[IOBluetoothCoreBluetoothCoordinator sharedInstance] pairPeer:[device classicPeer] forType:[pair currentPairingType] withKey:num]
• That wraps it up in an NSDictionary, adds some other stuff to it, and sends it over to bluetoothd using xpc

So what happens if we avoid the NSString-ification and call pairPeer:forType:withKey directly?

@interface IOBluetoothCoreBluetoothCoordinator : NSObject
+ (IOBluetoothCoreBluetoothCoordinator*)sharedInstance;
- (void)pairPeer:(id)peer forType:(NSUInteger)type withKey:(NSNumber*)key;
@end

@interface IOBluetoothDevice()
- (id)classicPeer;
@end

@interface IOBluetoothDevicePair()
- (void)setUserDefinedPincode:(BOOL)enabled;
- (NSUInteger)currentPairingType;
@end

@implementation MyPairingDelegate

- (void)devicePairingPINCodeRequest:(id)sender {
	IOBluetoothDevicePair* pair = (IOBluetoothDevicePair*)sender;
	IOBluetoothDevice* device = [sender device];
	const BluetoothDeviceAddress* addr = [device getAddress];
	BluetoothPINCode code;
	memset(&code, 0, sizeof(code));
	for (int i = 0; i < 6; i++) {
		code.data[i] = addr->data[5 - i];
	}
	uint64_t num;
	memcpy(&num, code.data, sizeof(num));
	[[IOBluetoothCoreBluetoothCoordinator sharedInstance] pairPeer:[device classicPeer] forType:[pair currentPairingType] withKey:@(num)];
	// [pair replyPINCode:6 PINCode:&code];
}

@end

...and we get slightly closer

IOBT -[IOBluetoothDevicePair _peerDidRequestPairing:type:passkey:]: User-defined Passcode found.
bluetoothd Sending 'pincode request' pairing event for device 40:D2:8A:B9:DA:F1
bluetoothd Received XPC message "CBClassicMsgIdPairingAgentRespondToPairing" from session "IOBT-5555494430aa5ffb00af38bd93f2bb29e76b2953-classic-99983-847"
bluetoothd handlePairingAgentRespondToPairing: Pincode (received as a number) 71273014745841 for the device "<private>"
<The rest is the same as above>

71273014745841 is 0x40D28AB9DAF1, which is the correct code (remember, this is little endian), it made it across this time. Sadly this still doesn't seem to be enough to pair.

I'm taking a break from this for now, if anyone else wants to look through bluetoothd code to see how it handles the code after this, I think that would be the next step. Or if anyone knows how to make bluetoothd not <private> its logs, that would also be helpful.

There's a profile at the bottom of this page which should uncensor <private>. All you need to do is copy and paste the profile data into a file with the extension .mobileconfig, and then double clicking it will start the import process.

https://www.cmdsec.com/unified-logs-enable-private-data/

Hi all!

I've finally figured it out! With macOS Monterey, Apple eliminated the older IOBluetoothHIDDriver interface for working with "Classic" Bluetooth devices (i.e., not Bluetooth Low Energy). The Wii Remote is Bluetooth 2.0, as far as I can tell. Bluetooth LE was only a thing starting with Bluetooth 4.0. Essentially, Bluetooth devices that use a standard lower than 4.0 will no longer work.

https://developer.apple.com/support/kernel-extensions/#:~:text=IOBluetoothHIDDriver,no%20longer%20supported.

We should probably note this in the wiki. Now that we know the DolphinBar works (and USB isn't ever going to be deprecated in macOS), we should recommend it to be used for users in the future.

That article is about kernel programming interfaces. Dolphin doesn't use those as far as I know.

I'd wanna test out this experimental patch on my M2 Macbook Air with Sonoma on it. I have classic and Motionplus Wiimotes that I can try out with it. How can I get a build up and running for this?

I was able to bypass the pairing process by extracting the link keys from my Mojave partition which is copied to Monterey. After doing so, the computer was able to read input from both Wii Remotes, and was able to work in Dolphin.

Where are those stored BTW? Kind of tempted to see how hard it would be to get a pair by doing the pairing on Linux and then copying the keys over to macOS...

Also throwing it out there that I am still available and willing to do any testing on Apple Silicon hardware.

Is it possible to @ people here? I really, really wanna see this (imo) very important issue resolved.

I made a separate app incorporating TellowKrinkle and jpapetti0713's research. It should pair the Wii Remote to your Mac. You can find it here: https://dl.dolphin-emu.org/misc/WiimotePair-1.0.dmg

Once that's done, you can press any button on it to have it connect. Dolphin's real Wii Remote features can then be used as normal (set a slot to "real Wii Remote" and then press Refresh).

Optimally, this code should probably be integrated into Dolphin, but I don't have the time to work out the details for that at the moment, hence the quickly made separate app.

Are you pressing the SYNC button at the back? Is this a third party Wii Remote or an official Nintendo one?

I´ve tried another remote and it works with that one. Thank you very much! :)

I can confirm that on my base model M2 Macbook Air on macOS 14.1.2, the app does not function. I opened the app, and it asked for Bluetooth permissions, and I gave it that. I tried both a classic Wiimote and a later Wiimote with Wii MotionPlus inside (I know there's a special model number for it but I cba to look it up right now). At some point, there was an alert from the app that one of the Wiimotes had synced, but there wasn't any function within Dolphin, and both of them later shut off automatically, stopping syncing. The stdout of the app didn't give any useful information.

Example output:
2024-02-10 16:58:29.715 WiimotePair[71845:3632735] -[IOBluetoothDeviceInquiry initWithDelegate:] - 0x600000729040

I'm not exactly sure what the issue might be but I will try any new updates as they come available.

leifdotwav wrote in #note-30:

there was an alert from the app that one of the Wiimotes had synced, but there wasn't any function within Dolphin

I had the same occur with Sonoma 14.3.1 and Dolphin 5.0-21116 on an M3 -- upon pairing to macOS, I then tried (and failed) to pair a balance board, without realizing the Wiimote pairing was a pyrrhic victory and wasn't usable in Dolphin, despite MacOS showing a Nintendo RVL-CNT-01 in my device list.

Okay, I actually did get my Wiimote working with my M3 Mac. It only worked after I installed WiiControler updated for macOS 12 from https://github.com/WiiController/WiiController/files/8007293/WiiController.dmg.zip and signing it -- only then did it maintain a bluetooth connection without disconnecting a few seconds later, and then when I launched Dolphin I felt it buzz and I was good to go. I don't know if WiiController actually helped, or if it was a coincidence, but it worked first try after installing WiiController. So, very happy I tried this -- there's definitely a solution here that needs to be upstreamed into Dolphin. At least one global nightmare is nearing it's end!

Hi! I'm running macOS 14.1.1 on my M1 MacBook Air and i'm unable to open WiiController. I've seen on the developer GitHub's page that if i'm running macOS 12 or higher, a kernel extension is required. What I do want to know is which is it, and why on that same page, the developer said that WiiController doesn't work for macOS 12 or higher. I'm a little confused.