Created attachment 576744 [details] Xorg.0.log from problem session Description of problem: After a suspend/resume cycle, X no longer recognises my Bluetooth mouse. - There's a confounding issue in that sometimes the Bt subsystem doesn't come back properly, see Bug 727106. Devices reappear after restarting the bluetooth service. - Following this, the mouse appears in the devices list in Gnome Shell, and other devices (e.g. file transfer from phone) works properly. - Upon reconnecting the mouse, messages like (WW) evdev: Bluetooth Mouse: device file is duplicate. Ignoring. appear in the Xorg logs (attached). Sometimes waiting for a few hours and then trying again works. I don't know if this is strictly an evdev bug. Might be udev or bluez or kernel or ... please reassign as appropriate. Version-Release number of selected component (if applicable): xorg-x11-drv-evdev-2.6.99.901-7.20120118git9d9c9870c.fc16.x86_64 udev-173-3.fc16.x86_64 bluez-4.96-3.fc16.x86_64 kernel-3.3.0-8.fc16.x86_64 kernel-3.3.1-2.fc16.x86_64 kernel-3.3.1-3.fc16.x86_64 xorg-x11-server-Xorg-1.11.4-3.fc16.x86_64 How reproducible: Intermittent, but frequent. Steps to Reproduce: 1. Suspend then resume. 2. Restart bluetooth.service if necessary, according to Bug 727106. 3. Reconnect Bluetooth mouse. Actual results: Mouse doesn't work. Expected results: Mouse works. Additional info:
*** Bug 811681 has been marked as a duplicate of this bug. ***
Either server or udev bug. The last parts of the log show that we get the "device added" event, but we never saw the "device removed" for it. The config_info string changes, so we don't automatically remove the previous instance when the new one is added. Lennart, any comments? Is there some race condition that we may suffer from in the server that we don't see the device removed event?
Are there any workarounds known, besides restarting X? I don't particularly like having to shut down all programs to restart X.
(In reply to comment #2) > Either server or udev bug. The last parts of the log show that we get the > "device added" event, but we never saw the "device removed" for it. > > The config_info string changes, so we don't automatically remove the > previous instance when the new one is added. > > Lennart, any comments? Is there some race condition that we may suffer from > in the server that we don't see the device removed event? Actually it's increasingly looking like a kernel bug - we're seeing the kernel netlink events with missing or corrupted components and also seeing other signs that pointers aren't going where they're supposed to...
Dan, you might probably just unplug and re-plug the mouse
Pierre-Yves: I have internal bluetooth so there is no possibility to unplug anything. However, I have tried cycling power on the mouse and have tried running "systemctl restart bluetooth.service" without success. Restarting X (by logging out and back in) works though.
Scott is referring to the debugging we've been doing on Chromium OS. We have some more details in the bug: http://code.google.com/p/chromium-os/issues/detail?id=33813 It's looking like a race condition in the kernel.
It is possible that this bug may not be related to bluetooth. I also have the same problem with a USB mouse. Unplugging and plugging back in doesn't fix the problem. This happens sometimes (well, once so far) when resuming from sleep. [603892.207] (II) config/udev: Adding input device PIXART USB OPTICAL MOUSE (/dev/input/mouse2) [603892.207] (II) No input driver specified, ignoring this device. [603892.207] (II) This device may have been added with another device file. [603892.209] (II) config/udev: Adding input device PIXART USB OPTICAL MOUSE (/dev/input/event12) [603892.209] (**) PIXART USB OPTICAL MOUSE: Applying InputClass "evdev pointer catchall" [603892.209] (II) Using input driver 'evdev' for 'PIXART USB OPTICAL MOUSE' [603892.209] (**) PIXART USB OPTICAL MOUSE: always reports core events [603892.209] (**) evdev: PIXART USB OPTICAL MOUSE: Device: "/dev/input/event12" [603892.209] (WW) evdev: PIXART USB OPTICAL MOUSE: device file is duplicate. Ignoring. [603892.227] (EE) PreInit returned 8 for "PIXART USB OPTICAL MOUSE" [603892.227] (II) UnloadModule: "evdev"
did you see a remove event for this device before event12 was added again? can't tell that from the log excerpt you posted, please always provide the full log.
I'm having the same problem with apple magic mouse, very frustrating...
this is what dmesg gives me: [ 8307.249323] power_supply hid-B8:F6:B1:1D:C8:F0-battery: driver failed to report `capacity' property: -5 [ 8311.915977] magicmouse 0005:05AC:030D.0007: unknown main item tag 0x0 [ 8311.922708] power_supply hid-B8:F6:B1:1D:C8:F0-battery: driver failed to report `capacity' property: -5 [ 8311.922916] input: Anthony’s Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/bluetooth/hci0/hci0:34/input18 [ 8311.923976] magicmouse 0005:05AC:030D.0007: input,hidraw0: BLUETOOTH HID v3.06 Mouse [Anthony’s Mouse] on 68:5D:43:20:DD:33 [ 8312.053764] traps: upowerd[3633] trap int3 ip:3cdee4e991 sp:7fffdb032dc0 error:0
Created attachment 626561 [details] another problem session As requested by Peter, a full log of a problem session.
I don't know if this helps, but I have found a way to have the mouse back after suspend (but you need to have a second pointer to do that!): before suspend, I have to turn off bluetooth (without turning it off my computer would randomly not suspend at all. anyway, without turning it off there is no chance to have the mouse back after wakeup), and after wakeup I need to turn it on in gnome-shell first, and then cycle the hardware button (disable, and then re-enable BT) to have BT with mouse back. Just cycling the hardware button does NOT work. I think there is something very wrong with the bluetooth drivers in the current kernel (3.6.1 here)! I even had kernel panics after wakeup with bluetooth enabled. For me this is a new thing as I've never actually used BT and always turned it off on startup by default to save battery life, but now that I have a bluetooth mouse I seem to have been thrown back six years in terms of linux useability. Any idea what to do with this?
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.