Red Hat Bugzilla – Bug 427677
Bluetooth mouse and keyboard (logitech dinovo) stop working after system is idle
Last modified: 2008-06-25 05:55:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168) Gecko/20071213 Fedora/22.214.171.124-3.fc8 Firefox/126.96.36.199
Description of problem:
Logitech DiNovo bluetooth mouse and keyboard are (usually) disabled after the system sits idle for a certain period of time. Usually the screen saver kicks in, which is set for 25 minutes.
In order to restore connectivity, I plug a usb keyboard in and use the gnome-bluetooth preferences dialog to:
(1) remove both mouse and keyboard from the input server; and
(2) add the mouse and keyboard to the input service.
Both devices will then work properly. I really like the bluetooth keyboard and mouse, but this is very annoying.
If I log out of the system in evening and return the next morning, the keyboard will usually (95%) be working but the mouse will not and will need to be enabled as above.
This may be related to bug 384591.
Once in a while after the system is idle, the mouse or the keyboard will still work but this is rare. So it gets a "sometimes but not always" tag. But sometimes is about 9 times out of 10.
See also http://article.gmane.org/gmane.linux.bluez.user/12988/match=dinovo for more information. I tried the udev rule suggested but was not successful. Probably due to an error on my part implementing the rule.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Lock system or just stop using it.
2. Return after 30 or more minutes
3. Keyboard and/or mouse, usually both unusable
Bluetooth keyboard and/or mouse no longer work.
Bluetooth keyboard and mouse should continue to work across all idle periods and system restarts.
This is a standard fedora 8 system with few addition packages, mainly from freshrpms.
Please show output of 'hcidump -XVt' when it stops working.
Created attachment 291085 [details]
hcidump -XVt > hcidump2.txt
hcidump as requested
At what point during that dump does it stop working? Can you show it with only
one device at a time? Is there anything in /var/log/messages when this happens?
i started the dump at the point after i logged in with the usb keyboard. the
pressed the keys on the keyboard a few times and moved the mouse a bit. hcidump
captured events but the mouse cursor does not move and key presses do not
display. then i opened the gnome bluetooth preferences application and dropped
both devices and then added them.
the log output only has the device creation:
Jan 8 13:28:17 pico input: Created input device: /org/bluez/input/pointing5
Jan 8 13:28:18 pico input: New input device 00:07:61:31:A8:B0 (Logitech
Jan 8 13:28:18 pico kernel: input: Logitech MX900 Mouse as /class/input/input15
Jan 8 13:28:40 pico input: Created input device: /org/bluez/input/keyboard6
Jan 8 13:29:36 pico input: Encryption link key not found
Jan 8 13:29:36 pico input: New input device 00:07:61:31:81:20 (Logitech
Jan 8 13:29:36 pico kernel: input: Logitech diNovo Keyboard as /class/input/input16
Jan 8 13:33:17 pico gnome-keyring-daemon: couldn't read 4 bytes from client:
i will create another dump that i start before the system is idle
Created attachment 291106 [details]
hcidump3.txt is started just as i leave the workstation for about 25 min. Close
to 1600 local time, i test the bluetooth keyboard only for response. Then use
usb keyboard to enter password and disconnect bluetooth keyboard. and then
reconnect keyboard. hcidump then terminated by using the bluetooth keyboard.
Mouse not touched until after hcidump terminated.
I seem to be bitten by the same bug on Fedora 9 on x86_64 architecture. Most of
the time my Mouse don't work at all, at connect time I usually get:
Couldn't display "obex://[00:07:61:BB:7A:F4]/".
Error: DBus error org.freedesktop.DBus.Error.NoReply: Message did not receive a
reply (timeout by message bus)
Please select another viewer and try again.
(In reply to comment #7)
> I seem to be bitten by the same bug on Fedora 9 on x86_64 architecture. Most of
> the time my Mouse don't work at all, at connect time I usually get:
> Couldn't display "obex://[00:07:61:BB:7A:F4]/".
Trying to browse files on a mouse will _obviously_ not work.
As for the mouse not reconnecting after disconnecting for power saving, it's a
kernel bug. Feel free to test the patch in the other bug and report whether it
fixes the problem for you.
*** This bug has been marked as a duplicate of 449872 ***