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 Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
