Comment 8 for bug 175743

I believe that Bug #220249 is another symptom of this same underlying bug, so it should probably be marked as a duplicate of this bug.

I have the same problem under Gnome on Hardy. I use a Logitech diNovo Media Desktop Laser keyboard and mouse combo. When one of the devices has been inactive for some time (20+ minutes, don't know how long for sure), that device will be disconnected as an X input device, but will still show up as connected according to bluez-utils and bluez-gnome programs (e.g., hcitool, bluetooth-properties, etc). Once I manually disconnect it via bluetooth-properties, then using the device again (i.e., pressing a key, if the BT keyboard fell asleep, or wiggling the BT mouse if the BT mouse fell asleep) will immediately cause the device to reconnect and be re-established as an X input device.

When both the BT keyboard and BT mouse are connected and active, `ls -l /dev/input/by-path` shows th the following symlinks to device files:

pci-0000:00:07.4-usb-0:aclXXYYXXYYXXYY- -> ../mouseX
pci-0000:00:07.4-usb-0:aclXXYYXXYYXXYY-event- -> ../eventY
pci-0000:00:07.4-usb-0:aclAABBAABBAABB-event- -> ../eventZ

where XXYYXXYYXXYY is the address of my BT mouse, AABBAABBAABB is the address of my BT keyboard, and ../mouseX, ../eventY, and ../eventZ are the device files for the mouse, the mouse events, and the keyboard events respectively.

If I let the BT keyboard fall asleep, then the keyboard event device file and the symlink are removed, but bluez-utils and bluez-gnome programs still shows the keyboard as being connected. Likewise, if I allow the BT mouse to fall asleep, its device files and symlinks are removed, but it is still listed as connected according to bluez-utils and bluez-gnome programs.

I hypothesize that some low-level bluez function detects that the device is asleep, and sends a dbus message to remove the device file, but that a higher-level function fails to get the signal, and therefore does not think that the device is disconnected; thus when the high-level function sees a request to re-connect, it drops it because it thinks the device is still connected. Alternatively, perhaps X somehow detects that no input has come in via a device, and removes the device file.

I am looking into the first possibility right now, but there are so many layers of frameworks and messages in the code that I am having a hard time figuring out what does what. Input from the bluez developers as to what dbus messages are sent and received in what modules would be greatly appreciated.