Description of problem: Maybe 5x per day, my bluetooth mouse stops working, and shortly thereafter gnome-bluetooth settings UI says that it's disconnected. Manual reconnection resumes functionality until the next time it disconnects for unknown reasons. I can't tell if this is a gdm-x-session, udev, bluetoothd, or a libinput bug. This is not a regression, it happens the same in Fedora 23. The problem doesn't happen with the same hardware setup using OS X. Version-Release number of selected component (if applicable): kernel-4.5.5-300.fc24.x86_64 gnome-bluetooth-3.20.0-1.fc24.x86_64 How reproducible: Not reproducible, happens randomly but does eventually always happen. Steps to Reproduce: 1. Use the system 2. 3. Actual results: Eventually the mouse stops responding to both tracking and clicks. About 10 seconds later, settings > bluetooth says the mouse is disconnected. Expected results: The mouse shouldn't disconnect. Additional info: This is the first indication of a problem that I can find: [34388.580290] f24m /usr/libexec/gdm-x-session[1693]: (II) config/udev: removing device mouses [34388.580483] f24m /usr/libexec/gdm-x-session[1693]: (**) Option "fd" "37" [34388.580742] f24m /usr/libexec/gdm-x-session[1693]: (II) UnloadModule: "libinput" [34388.580837] f24m /usr/libexec/gdm-x-session[1693]: (II) systemd-logind: releasing fd for 13:71 [34388.592012] f24m bluetoothd[825]: GLib: Source ID 779 was not found when attempting to remove it There are no kernel messages at this time frame.
Created attachment 1162629 [details] journal journalctl -b
I'm having very similar issues in Fedora 23 in Gnome 3. The only way to get the mouse working again is to flip the switch on the laptop to turn off all the radios and then turn it back on again. Then I can bring the hci0 controller backup manually and things reconnect. This only happens in Gnome. It does not happen to me while use KDE Plasma on the exact same hardware.
(In reply to Kurt Bechstein from comment #2) Concur. As originally reported I was not using WiFi, but now I am, and when Bluetooth drops the mouse, I have to first turn off WiFi in order to reconnect the Bluetooth mouse. If I don't turn WiFi off, switching Bluetooth from Off to On results in a pause then the switch flips itself back from On to Off with no informational or error message at all.
So I was just working along in gnome 3 and my bluetooth mouse cut out on me again. The only thing I could find in the logs was the following: kernel: usb 1-1.3: reset full-speed USB device number 3 using ehci-pci For whatever reason this issue doesn't happen while using another desktop environment. Here is the information from hciconfig -a: hci0: Type: BR/EDR Bus: USB BD Address: 0C:8B:FD:EC:17:C3 ACL MTU: 1021:5 SCO MTU: 96:5 DOWN RX bytes:567887 acl:28266 sco:0 events:3686 errors:0 TX bytes:27122 acl:20 sco:0 commands:205 errors:0 Features: 0xff 0xfe 0x0f 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF Link mode: SLAVE ACCEPT If I try to bring up the controller: hciconfig hci0 up Can't init device hci0: Connection timed out (110) Output from bluetoothctl as I switch off the radio switch on the laptop: bluetoothctl [NEW] Controller 0C:8B:FD:EC:17:C3 localhost.localdomain [default] [NEW] Device 1C:E6:C7:9A:4F:AC CP-8945 [NEW] Device 1C:E6:C7:9A:53:02 CP-8945 [NEW] Device C0:33:5E:02:1B:0B Microsoft Sculpt Comfort Mouse [NEW] Device 1C:E6:C7:9B:55:E4 CP-8945 [DEL] Device 1C:E6:C7:9B:55:E4 CP-8945 [DEL] Device C0:33:5E:02:1B:0B Microsoft Sculpt Comfort Mouse [DEL] Device 1C:E6:C7:9A:53:02 CP-8945 [DEL] Device 1C:E6:C7:9A:4F:AC CP-8945 [DEL] Controller 0C:8B:FD:EC:17:C3 localhost.localdomain [default] Output from bluetoothctl as I turn the radio switch back on: [NEW] Controller 0C:8B:FD:EC:17:C3 localhost.localdomain [default] [NEW] Device 1C:E6:C7:9B:55:E4 CP-8945 [NEW] Device C0:33:5E:02:1B:0B Microsoft Sculpt Comfort Mouse [NEW] Device 1C:E6:C7:9A:53:02 CP-8945 [NEW] Device 1C:E6:C7:9A:4F:AC CP-8945 [CHG] Controller 0C:8B:FD:EC:17:C3 UUIDs: 00001112-0000-1000-8000-00805f9b34fb [CHG] Controller 0C:8B:FD:EC:17:C3 UUIDs: 00001801-0000-1000-8000-00805f9b34fb [CHG] Controller 0C:8B:FD:EC:17:C3 UUIDs: 0000110e-0000-1000-8000-00805f9b34fb [CHG] Controller 0C:8B:FD:EC:17:C3 UUIDs: 00001800-0000-1000-8000-00805f9b34fb [CHG] Controller 0C:8B:FD:EC:17:C3 UUIDs: 00001200-0000-1000-8000-00805f9b34fb [CHG] Controller 0C:8B:FD:EC:17:C3 UUIDs: 0000110c-0000-1000-8000-00805f9b34fb [CHG] Controller 0C:8B:FD:EC:17:C3 UUIDs: 0000110a-0000-1000-8000-00805f9b34fb [CHG] Controller 0C:8B:FD:EC:17:C3 UUIDs: 0000110b-0000-1000-8000-00805f9b34fb [CHG] Controller 0C:8B:FD:EC:17:C3 Class: 0x0c010c [CHG] Controller 0C:8B:FD:EC:17:C3 Powered: yes [CHG] Controller 0C:8B:FD:EC:17:C3 Class: 0x000000 [CHG] Controller 0C:8B:FD:EC:17:C3 Powered: no [CHG] Controller 0C:8B:FD:EC:17:C3 Discovering: no Controller is still in down state: hciconfig -a hci0: Type: BR/EDR Bus: USB BD Address: 0C:8B:FD:EC:17:C3 ACL MTU: 1021:5 SCO MTU: 96:5 DOWN RX bytes:1337 acl:0 sco:0 events:155 errors:0 TX bytes:25761 acl:0 sco:0 commands:154 errors:0 Features: 0xff 0xfe 0x0f 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF Bring the interface up: hciconfig hci0 up hciconfig -a hci0: Type: BR/EDR Bus: USB BD Address: 0C:8B:FD:EC:17:C3 ACL MTU: 1021:5 SCO MTU: 96:5 UP RUNNING PSCAN ISCAN RX bytes:1947 acl:0 sco:0 events:191 errors:0 TX bytes:26463 acl:0 sco:0 commands:190 errors:0 Features: 0xff 0xfe 0x0f 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF Link mode: SLAVE ACCEPT Name: 'localhost.localdomain' Class: 0x0c010c Service Classes: Rendering, Capturing Device Class: Computer, Laptop HCI Version: 4.0 (0x6) Revision: 0x500 LMP Version: 4.0 (0x6) Subversion: 0x500 Manufacturer: Intel Corp. (2) At this point everything is now working. This whole process happens about 3-4 times every day while using Gnome in F23 but not in Plasma.
I have the same issue with Fedora 24. Mouse randomly disconnects, however in my case it automatically reconnects. I feel I trigger it to reconnect by moving the mouse around. Dec 26 09:55:19 xps /usr/libexec/gdm-x-session[1797]: (II) config/udev: removing device Bluetooth Mouse M557 Dec 26 09:55:19 xps /usr/libexec/gdm-x-session[1797]: (**) Option "fd" "39" Dec 26 09:55:19 xps /usr/libexec/gdm-x-session[1797]: (II) UnloadModule: "libinput" Dec 26 09:55:19 xps /usr/libexec/gdm-x-session[1797]: (II) systemd-logind: not releasing fd for 13:70, still in use Dec 26 09:55:19 xps /usr/libexec/gdm-x-session[1797]: (II) config/udev: removing device Bluetooth Mouse M557 Dec 26 09:55:19 xps /usr/libexec/gdm-x-session[1797]: (**) Option "fd" "39" Dec 26 09:55:19 xps /usr/libexec/gdm-x-session[1797]: (II) UnloadModule: "libinput" Dec 26 09:55:19 xps /usr/libexec/gdm-x-session[1797]: (II) systemd-logind: releasing fd for 13:70 Dec 26 09:55:20 xps kernel: hid-generic 0005:046D:B010.0014: unknown main item tag 0x0 Dec 26 09:55:20 xps kernel: input: Bluetooth Mouse M557 as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/bluetooth/hci0/hci0:11/0005:046D:B010.0014/input/input40 Dec 26 09:55:20 xps kernel: hid-generic 0005:046D:B010.0014: input,hidraw2: BLUETOOTH HID v10.01 Mouse [Bluetooth Mouse M557] on c4:8e:8f:f8:87:40 Dec 26 09:55:20 xps /usr/libexec/gdm-x-session[1797]: (II) config/udev: Adding input device Bluetooth Mouse M557 (/dev/input/mouse0) Dec 26 09:55:20 xps /usr/libexec/gdm-x-session[1797]: (**) Bluetooth Mouse M557: Applying InputClass "system-keyboard" Dec 26 09:55:20 xps /usr/libexec/gdm-x-session[1797]: (II) No input driver specified, ignoring this device. Dec 26 09:55:20 xps /usr/libexec/gdm-x-session[1797]: (II) This device may have been added with another device file. Dec 26 09:55:20 xps upowerd[1612]: (upowerd:1612): UPower-Linux-WARNING **: treating change event as add on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/bluetooth/hci0/hci0:11/0005:046D:B010.0014/power_supply/hid-00:1f:20:f4:3d:ec-battery Dec 26 09:55:20 xps /usr/libexec/gdm-x-session[1797]: (II) config/udev: Adding input device Bluetooth Mouse M557 (/dev/input/event6) Dec 26 09:55:20 xps /usr/libexec/gdm-x-session[1797]: (**) Bluetooth Mouse M557: Applying InputClass "evdev pointer catchall" ... And many more mouse messages
Problem still exist with fedora 25
It looks I have solved all my bluetooth mouse issues by providing a firmware patch at /lib/firmware/brcm I discovered the following 2 error messages: bluetooth hci0: Direct firmware load for brcm/BCM20702A1-0a5c-216f.hcd failed with error -2 bluetooth hci0: BCM: Patch brcm/BCM20702A1-0a5c-216f.hcd not found Googling the error lead me to a site explaining how to extract the patch from an MS Windows driver. No that I have installed the patch I have no more disconnects and lagging for a few days.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Why was this closed? Comment #6 very clearly states that this problem still happens on Fedora 25. The Version: should have been updated at that point, not the ticket being closed. This problem still exists on Fedora 26. Would somebody who has permission please reopen this ticket and set the Version: to 26?