From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.10) Gecko/20071213 Fedora/2.0.0.10-3.fc8 Firefox/2.0.0.10 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): bluez-libs-3.20-1.fc8.x86_64 How reproducible: Sometimes 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 Actual Results: Bluetooth keyboard and/or mouse no longer work. Expected Results: Bluetooth keyboard and mouse should continue to work across all idle periods and system restarts. Additional info: 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[2350]: Created input device: /org/bluez/input/pointing5 Jan 8 13:28:18 pico input[2350]: New input device 00:07:61:31:A8:B0 (Logitech MX900 Mouse) Jan 8 13:28:18 pico kernel: input: Logitech MX900 Mouse as /class/input/input15 Jan 8 13:28:40 pico input[2350]: Created input device: /org/bluez/input/keyboard6 Jan 8 13:29:36 pico input[2350]: Encryption link key not found Jan 8 13:29:36 pico input[2350]: New input device 00:07:61:31:81:20 (Logitech diNovo Keyboard) Jan 8 13:29:36 pico kernel: input: Logitech diNovo Keyboard as /class/input/input16 Jan 8 13:33:17 pico gnome-keyring-daemon[2880]: couldn't read 4 bytes from client:
i will create another dump that i start before the system is idle
Created attachment 291106 [details] as requested 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 ***