I chat lately with a Apple bluetooth developer.
The problem comes from the fact that the Bluetooth HID implementation in Mac OS X is broken.
The Wiimote is not an HID compliant device, but exposes a HID header when purposely queried.
When a connection is inited with the Wiimote, the kernel thinks it is a HID device, and tries to get a hold on the device. As the device can share only one connection at a time with the computer (this is the definition of a L2CAP channel), the connection is lost on the user side, and eventually fails on the kernel side, hence the mess.
But the kernel is not able to catch the Wiimote every time, this is why it works when there's no entry in the Bluetooth devices list, and also on multi-core systems, it seems the connection process is more stable.
I look forward the Leopard implementation of Bluetooth, though the developer said to me it was not planned to actually change the way Bluetooth HID is implemented right now. We can only hope he was under NDA, and was not telling the truth ...
Best,
Camille
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The developers of RemoteBuddy seem to have found a solution for this problem. They use a self-made kernel extension to connect to the Wii remote, and it appears their implementation can always connect to the Wii remote. Too bad they didn't share their knowledge on that issue (or did I miss something?)
So at least there IS a way to do it right and there's only one question left: who wants to implement an open kext? :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I actually downloaded remote buddy and installed it. as part of the installation process, it installs the kernel extension intended to fix the bluetooth stack HID problem.
And, as I had hoped ... VOILA! ... .Darwiin Remote now seems to work pretty darn well :)
I can kill the wii remote connection once it has connected (by pressing the power button on the remote), and then re-synchronize by either pressing the synch button, or
holding down buttons 1 and 2. It re-connects without fail, and i also have the ability to control the LEDs and Force Feedback (which means that the channel from computer -> remote, i.e. cchan, is functional!)
So, besides costing 20 euros, this doesn't seem like a bad solution :) You can download RemoteBuddy for a free 30-day trial.
Please let me know if others have this same experience ....
Best,
Dan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have the same problem described everywhere with my PowerBook G4 -- need to go into Bluetooth System Preferences every time and delete the Wiimote there, then connect to it from DarwiinRemote. Since I'm trying to write a Wiimote driver for my Mac media center app (http://giesler.biz/~bjoern/en/sw_couchpotato.html), that's not acceptable, so I'm looking for every hint.
I just downloaded the trial of RemoteBuddy and installed the KEXT that comes with it. That doesn't seem to change anything. Did you do anything else, or did it work for you right after loading the KEXT?
Regards,
Björn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For me it seems that you must have loaded the RemoteBuddy app itself (not only the kext) to ensure that your own DarwiinRemote app gets always connected.
HTH!
I'm in doubt that writing own kexts for every application is a really good idea. If all developers write their own kexts, the different drivers will for sure interfere with each other...
If the evidence (somewhere in this forum) of a future version of OSX with HID drivers that don't block Wii remote connections is wrong, the only solution to this seems to be an open kext.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for not being more specific in my last post, bjoerng. I have indeed experienced the same behavior as hypo__ ... Remote Buddy needs to be installed and *running* for the kernel extension to be active, and for the Wii Remote framework to function properly on a PowerPC machine.
I haven't done much kernel programming before, but I assume that when Remote Buddy starts up, it calls something in the kernel extension to initialize it, so that the kernel properly handles the L2CAP bluetooth connections from the Wii Remote. I feel like there should be some way to call those same initialize routines from any client app you write (for example, Darwin Remote). Can anyone that knows more than I do about kernel programming (which is to say, knows anything at all about it:) comment on this?
Also - bjoerng - if you're looking for a really hacky way to get the WiiRemote framework to work on a PowerPC machine without having to manually delete the Wii Remote from the bluetooth recent devices list, try using /usr/sbin/kextstat to see what kernel extensions are loaded when you connect the Wii Remote, and then unload them before trying to connect the Wii Remote again. For example, on my PowerPC, the following kernel extensions are loaded when I connect the Wii Remote:
com.apple.driver.AppleHIDMouse
com.apple.iokit.IOUSBHIDDriver
IOBluetoothHIDDriver
If, after a failed connection attempt, I use the following code to unload these kernel extensions:
system("sudo /sbin/kextunload -b com.apple.driver.AppleHIDMouse");
system("sudo /sbin/kextunload -b com.apple.iokit.IOUSBHIDDriver");
system("sudo /sbin/kextunload -b IOBluetoothHIDDriver");
it seems that I am able to re-connect without a problem.
This is, as I said, an un-ideal solution, for several reasons First off, you need to authenticate (sudo) to do it. Also, after you issue these commands just once and the kexts are unloaded, it seems that my computer won't automatically load these extensions again. I.e. if i try to connect my USB mouse after issuing these commands, my computer won't recognize input from it. So ... as i said ... not a great solution :(
Dan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
so, to warm up this thread: The RemoteBuddy method doesn't work on my box, and the kexts Dan mentioned don't show up in my kextstat output... but, my last hope, Leopard is out. Has anyone who had this error tried DarwiinRemote on Leopard yet and can say if the problem is still there?
Thanks a lot in advance,
Björn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using the prebuilt binary v.0.7 on my 10.5.8 Intel system, I can connect quite reliably to the remote. /var/log/system says
only:
May 11 20:40:54 kernel: Error retrieving device properties.
May 11 20:40:54 kernel: Couldn't retrieve device properties
I can even connect to a balance board (without reading values), with slightly different /var/log/system output:
May 11 20:43:31 nicolas blued: addDeviceToHIDEmulationMode - unrecognized HID device; NOT storing the link keys to the module.
May 11 20:43:31 blued: isCSR: 0 isBRCM: 1
May 11 20:43:31 blued: major class: 5 minor class: 1
May 11 20:43:31 kernel: staticPrepControlChannelAction returned error e00002bc
May 11 20:43:31 kernel: Failed.
However when I use the SVN version 240, carefully removing the Nintendo enties in the Bluetooth prefs beforehand,
I only get the discovery error -536870195, both for the balance board and the remote; with the system log:
May 11 20:45:44 DarwiinRemote: Wii instantiated
May 11 20:45:44 DarwiinRemote: Open channel (PSM:17) …
May 11 20:45:45 kernel: IOMemoryDescriptor: attempt to create 32b virtual in 64b task, use ::withAddressRange()
May 11 20:45:45 kernel: Backtrace 0x430605 0x4304f5 0x42ff40 0x55038646 0x427525 0x55038548 0x4416d4
May 11 20:45:45 DarwiinRemote: Could not open L2CAP channel (psm:17)
May 11 20:45:45 kernel: Kernel loadable modules in backtrace (with dependencies):
May 11 20:45:45 kernel: com.apple.iokit.IOBluetoothFamily(2.1.9f10)@0x55028000->0x55061fff
May 11 20:45:45 DarwiinRemote: Wii released
I was particularly interested in the balance board support in the SVN version, could that be built as a
binary release soon?
thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been able to use DarwiinRemote. But the second time trying to connect it fails with the following error.
I tried rebooting with no success.
Please press 1 button and 2 button simultaneously
===== WiiRemoteDiscovery error (268435459) =====
===== WiiRemoteDiscovery error (268435459) =====
===== WiiRemoteDiscovery error (268435459) =====
great project
thanks
hi Mauricio,
hmm...strange.
I'm not sure the actual causes, but please try followings.
1. open System Preferences
2. Choose Bluetooth
3. In device tab, delete bluetooth devices named "Nintendo RVL-CNT-01"
Thanks,
Hiroaki
Hi everybody,
I chat lately with a Apple bluetooth developer.
The problem comes from the fact that the Bluetooth HID implementation in Mac OS X is broken.
The Wiimote is not an HID compliant device, but exposes a HID header when purposely queried.
When a connection is inited with the Wiimote, the kernel thinks it is a HID device, and tries to get a hold on the device. As the device can share only one connection at a time with the computer (this is the definition of a L2CAP channel), the connection is lost on the user side, and eventually fails on the kernel side, hence the mess.
But the kernel is not able to catch the Wiimote every time, this is why it works when there's no entry in the Bluetooth devices list, and also on multi-core systems, it seems the connection process is more stable.
I look forward the Leopard implementation of Bluetooth, though the developer said to me it was not planned to actually change the way Bluetooth HID is implemented right now. We can only hope he was under NDA, and was not telling the truth ...
Best,
Camille
The developers of RemoteBuddy seem to have found a solution for this problem. They use a self-made kernel extension to connect to the Wii remote, and it appears their implementation can always connect to the Wii remote. Too bad they didn't share their knowledge on that issue (or did I miss something?)
So at least there IS a way to do it right and there's only one question left: who wants to implement an open kext? :-)
I wish I knew that people had discovered this, as I spent 1 hour figuring this out. :P
Hello -
Good find, hypo__ !!
I actually downloaded remote buddy and installed it. as part of the installation process, it installs the kernel extension intended to fix the bluetooth stack HID problem.
And, as I had hoped ... VOILA! ... .Darwiin Remote now seems to work pretty darn well :)
I can kill the wii remote connection once it has connected (by pressing the power button on the remote), and then re-synchronize by either pressing the synch button, or
holding down buttons 1 and 2. It re-connects without fail, and i also have the ability to control the LEDs and Force Feedback (which means that the channel from computer -> remote, i.e. cchan, is functional!)
So, besides costing 20 euros, this doesn't seem like a bad solution :) You can download RemoteBuddy for a free 30-day trial.
Please let me know if others have this same experience ....
Best,
Dan
Hi Dan,
I have the same problem described everywhere with my PowerBook G4 -- need to go into Bluetooth System Preferences every time and delete the Wiimote there, then connect to it from DarwiinRemote. Since I'm trying to write a Wiimote driver for my Mac media center app (http://giesler.biz/~bjoern/en/sw_couchpotato.html), that's not acceptable, so I'm looking for every hint.
I just downloaded the trial of RemoteBuddy and installed the KEXT that comes with it. That doesn't seem to change anything. Did you do anything else, or did it work for you right after loading the KEXT?
Regards,
Björn
For me it seems that you must have loaded the RemoteBuddy app itself (not only the kext) to ensure that your own DarwiinRemote app gets always connected.
HTH!
I'm in doubt that writing own kexts for every application is a really good idea. If all developers write their own kexts, the different drivers will for sure interfere with each other...
If the evidence (somewhere in this forum) of a future version of OSX with HID drivers that don't block Wii remote connections is wrong, the only solution to this seems to be an open kext.
Hi -
Sorry for not being more specific in my last post, bjoerng. I have indeed experienced the same behavior as hypo__ ... Remote Buddy needs to be installed and *running* for the kernel extension to be active, and for the Wii Remote framework to function properly on a PowerPC machine.
I haven't done much kernel programming before, but I assume that when Remote Buddy starts up, it calls something in the kernel extension to initialize it, so that the kernel properly handles the L2CAP bluetooth connections from the Wii Remote. I feel like there should be some way to call those same initialize routines from any client app you write (for example, Darwin Remote). Can anyone that knows more than I do about kernel programming (which is to say, knows anything at all about it:) comment on this?
Also - bjoerng - if you're looking for a really hacky way to get the WiiRemote framework to work on a PowerPC machine without having to manually delete the Wii Remote from the bluetooth recent devices list, try using /usr/sbin/kextstat to see what kernel extensions are loaded when you connect the Wii Remote, and then unload them before trying to connect the Wii Remote again. For example, on my PowerPC, the following kernel extensions are loaded when I connect the Wii Remote:
com.apple.driver.AppleHIDMouse
com.apple.iokit.IOUSBHIDDriver
IOBluetoothHIDDriver
If, after a failed connection attempt, I use the following code to unload these kernel extensions:
system("sudo /sbin/kextunload -b com.apple.driver.AppleHIDMouse");
system("sudo /sbin/kextunload -b com.apple.iokit.IOUSBHIDDriver");
system("sudo /sbin/kextunload -b IOBluetoothHIDDriver");
it seems that I am able to re-connect without a problem.
This is, as I said, an un-ideal solution, for several reasons First off, you need to authenticate (sudo) to do it. Also, after you issue these commands just once and the kexts are unloaded, it seems that my computer won't automatically load these extensions again. I.e. if i try to connect my USB mouse after issuing these commands, my computer won't recognize input from it. So ... as i said ... not a great solution :(
Dan
Hi,
so, to warm up this thread: The RemoteBuddy method doesn't work on my box, and the kexts Dan mentioned don't show up in my kextstat output... but, my last hope, Leopard is out. Has anyone who had this error tried DarwiinRemote on Leopard yet and can say if the problem is still there?
Thanks a lot in advance,
Björn
Yep. The problem is still there in 10.5. B^(
- Jasen.
dan_greenblat said:
Are you sure you need to unload all of those?
This is just from my perspective, but the first one I think just gives the mouse priority as mouse, and the second lets in connect by USB
I'd try unloading only the last one, IOBluetoothHIDDriver
Using the prebuilt binary v.0.7 on my 10.5.8 Intel system, I can connect quite reliably to the remote. /var/log/system says
only:
I can even connect to a balance board (without reading values), with slightly different /var/log/system output:
However when I use the SVN version 240, carefully removing the Nintendo enties in the Bluetooth prefs beforehand,
I only get the discovery error -536870195, both for the balance board and the remote; with the system log:
I was particularly interested in the balance board support in the SVN version, could that be built as a
binary release soon?
thanks
I am also having this problem, darwiin never connects to the wii no matter how many times I delete it in bluetooth settings, any tips?