Comment 132 for bug 32415

Hi All,
I am new to this discussion, just tripped over it while looking for something totally different.
If I say something silly, please let me know. Just trying to help, but I may be totally wrong here :-)

My understanding of the symptoms:
- a bluetooth mouse or keyboard, regardless of the brand or chipset, will stop working when GDM comes up
- reconnecting explicitely the device(s) at that point restores the device functionality, but then it is not working anymore at next boot, until GDM is up and running again
- the problem seems system dependant

It looks like the devices stop working at the exact moment when the Bluetooth stack is loaded and the adapter is switched from HID to HCI mode. Despite knowing the device address, the stack fails in reconnecting the device.

A similar problem can occur if there is a discrepancy in Bluetooth link key inside the broadcom BT adapter in HID mode, and the link key stored by the host stack.

Again, I have no clue about the actual implementation of Dapper (actually I heard that name for the first time today :-), but my guess is that there must be some code / HCI commands missing to synchronize the link keys, or alternatively that depending on the silicon used that synchronisation does not work as expected, and requires some undocumented commands. If not done already, it would probably help to look at the HCI traffic on USB on the original OS supplied with the machine (MacOS X) and compare it with what Dapper does.