Bug 427677 - Bluetooth mouse and keyboard (logitech dinovo) stop working after system is idle
Bluetooth mouse and keyboard (logitech dinovo) stop working after system is idle
Status: CLOSED DUPLICATE of bug 449872
Product: Fedora
Classification: Fedora
Component: bluez-libs (Show other bugs)
8
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: David Woodhouse
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-06 11:43 EST by Brad Smith
Modified: 2008-06-25 05:55 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-25 05:55:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
hcidump -XVt > hcidump2.txt (111.52 KB, text/plain)
2008-01-08 15:28 EST, Brad Smith
no flags Details
as requested (55.73 KB, text/plain)
2008-01-08 19:44 EST, Brad Smith
no flags Details

  None (edit)
Description Brad Smith 2008-01-06 11:43:38 EST
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.
Comment 1 David Woodhouse 2008-01-06 12:30:55 EST
Please show output of 'hcidump -XVt' when it stops working.
Comment 2 Brad Smith 2008-01-08 15:28:39 EST
Created attachment 291085 [details]
hcidump -XVt > hcidump2.txt

hcidump as requested
Comment 3 David Woodhouse 2008-01-08 16:11:29 EST
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?
Comment 4 Brad Smith 2008-01-08 16:59:54 EST
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: 
Comment 5 Brad Smith 2008-01-08 17:02:27 EST
i will create another dump that i start before the system is idle
Comment 6 Brad Smith 2008-01-08 19:44:35 EST
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.
Comment 7 Knut-Håvard Aksnes 2008-06-25 03:49:26 EDT
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.
Comment 8 Bastien Nocera 2008-06-25 05:55:25 EDT
(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 ***

Note You need to log in before you can comment on or make changes to this bug.