Bug 811534 - X ignoring Bluetooth mouse after suspend/resume cycle
X ignoring Bluetooth mouse after suspend/resume cycle
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
:
: 811681 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-11 07:00 EDT by James
Modified: 2013-02-13 21:11 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 21:11:35 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg.0.log from problem session (93.27 KB, text/plain)
2012-04-11 07:00 EDT, James
no flags Details
another problem session (116.21 KB, text/plain)
2012-10-13 10:00 EDT, Dan Stahlke
no flags Details

  None (edit)
Description James 2012-04-11 07:00:10 EDT
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:
Comment 1 Peter Hutterer 2012-04-19 21:38:27 EDT
*** Bug 811681 has been marked as a duplicate of this bug. ***
Comment 2 Peter Hutterer 2012-04-19 22:31:11 EDT
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?
Comment 3 Dan Stahlke 2012-08-27 17:29:57 EDT
Are there any workarounds known, besides restarting X?  I don't particularly like having to shut down all programs to restart X.
Comment 4 Scott James Remnant 2012-08-27 17:49:57 EDT
(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...
Comment 5 Pierre-Yves Luyten 2012-08-27 18:00:09 EDT
Dan, you might probably just unplug and re-plug the mouse
Comment 6 Dan Stahlke 2012-08-27 18:26:09 EDT
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.
Comment 7 Andrew de los Reyes 2012-08-28 16:51:52 EDT
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.
Comment 8 Dan Stahlke 2012-09-12 09:59:24 EDT
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"
Comment 9 Peter Hutterer 2012-10-08 19:27:42 EDT
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.
Comment 10 kpijarski 2012-10-13 06:02:16 EDT
I'm having the same problem with apple magic mouse, very frustrating...
Comment 11 kpijarski 2012-10-13 06:04:55 EDT
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
Comment 12 Dan Stahlke 2012-10-13 10:00:46 EDT
Created attachment 626561 [details]
another problem session

As requested by Peter, a full log of a problem session.
Comment 13 kpijarski 2012-10-17 00:00:48 EDT
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?
Comment 14 Fedora End Of Life 2013-02-13 21:11:44 EST
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.

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