[Bug 175743] Re: Bluetooth Mouse looses connection after some time of inactivity

[Robert Lange]

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.

** Also affects: bluez-gnome (Ubuntu)
   Importance: Undecided
       Status: New

-- 
Bluetooth Mouse looses connection after some time of inactivity
https://bugs.launchpad.net/bugs/175743
You received this bug notification because you are a member of
Bluetooth, which is subscribed to bluez-utils in ubuntu.