GNOME Bugzilla – Bug 767820
failure to connect to previously paired mouse, and no error given to the user why it won't connect
Last modified: 2019-03-20 10:40:06 UTC
I have a bluetooth mouse that always needs manual connection everytime I boot/reboot. So I go to Settings > Bluetooth > click on the device name which also says it's Disconnected, and I get a dialog for this mouse with a Connection switch that's Off. I slide it to On, and after a few seconds it flips back to Off with no error message. So there are two bugs: one the user isn't given any error information why it's not connected, so troubleshooting this is made more difficult; and the second problem is that it's not actually being connected. journal reports only: Jun 18 10:17:34 f24m bluetoothd[2542]: Can't get HIDP connection info Jun 18 10:17:39 f24m bluetoothd[2542]: connect error: Host is down (112) [root@f24m ~]# rfkill list 0: hci0: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no [root@f24m ~]# hciconfig hci0: Type: BR/EDR Bus: USB BD Address: E0:F8:47:39:5D:DF ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING PSCAN ISCAN RX bytes:2403 acl:0 sco:0 events:181 errors:0 TX bytes:4182 acl:0 sco:0 commands:141 errors:0 So it could be a bluez bug because clearly the host is up. But nevertheless the silent fail is also a bug.
bluez-5.40-1.fc24.x86_64 gnome-bluetooth-3.20.0-1.fc24.x86_64 gnome-settings-daemon-3.20.1-3.fc24.x86_64
If I turn off WiFi first, then changing Connection state Off to On sticks and the mouse works. But still there's no error message giving me any hint I have to turn off WiFi, and of course I probably shouldn't have to turn off WiFi in the first place. Before turning off WiFi: [root@f24m ~]# rfkill list 0: hci0: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no [root@f24m ~]# hciconfig hci0: Type: BR/EDR Bus: USB BD Address: E0:F8:47:39:5D:DF ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING PSCAN RX bytes:557419 acl:26881 sco:0 events:374 errors:0 TX bytes:9052 acl:77 sco:0 commands:168 errors:0 After turning off WiFi [root@f24m ~]# rfkill list 0: hci0: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: yes Hard blocked: no [root@f24m ~]# hciconfig hci0: Type: BR/EDR Bus: USB BD Address: E0:F8:47:39:5D:DF ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:635912 acl:30510 sco:0 events:444 errors:0 TX bytes:11098 acl:101 sco:0 commands:194 errors:0 And this is what appears in journalctl -f the moment I click on mouse > Connection > Off to On. Jun 18 12:32:34 f24m bluetoothd[838]: Can't get HIDP connection info Jun 18 12:32:38 f24m audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Jun 18 12:32:45 f24m kernel: magicmouse 0005:05AC:030D.0009: unknown main item tag 0x0 Jun 18 12:32:45 f24m kernel: input: mouses as /devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.3/1-1.1.3:1.0/bluetooth/hci0/hci0:12/0005:05AC:030D.0009/input/input18 Jun 18 12:32:45 f24m kernel: magicmouse 0005:05AC:030D.0009: input,hidraw1: BLUETOOTH HID v3.06 Mouse [mouses] on e0:f8:47:39:5d:df Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (II) config/udev: Adding input device mouses (/dev/input/mouse0) Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (II) No input driver specified, ignoring this device. Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (II) This device may have been added with another device file. Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (II) config/udev: Adding input device mouses (/dev/input/event7) Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (**) mouses: Applying InputClass "evdev pointer catchall" Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (**) mouses: Applying InputClass "libinput pointer catchall" Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (II) systemd-logind: got fd for /dev/input/event7 13:71 fd 36 paused 0 Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (II) Using input driver 'libinput' for 'mouses' Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (**) mouses: always reports core events Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (**) Option "Device" "/dev/input/event7" Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (**) Option "_source" "server/udev" Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (II) input device 'mouses', /dev/input/event7 is tagged by udev as: Mouse Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (II) input device 'mouses', /dev/input/event7 is a pointer caps Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.1/1-1.1.3/1-1.1.3:1.0/bluetooth/hci0/hci0:12/0005:05AC:030D.0009/input/input18/event7" Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (II) XINPUT: Adding extended input device "mouses" (type: MOUSE, id 9) Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (**) Option "AccelerationScheme" "none" Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (**) mouses: (accel) selected scheme none/0 Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (**) mouses: (accel) acceleration factor: 2.000 Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (**) mouses: (accel) acceleration threshold: 4 Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (II) input device 'mouses', /dev/input/event7 is tagged by udev as: Mouse Jun 18 12:32:45 f24m /usr/libexec/gdm-x-session[4365]: (II) input device 'mouses', /dev/input/event7 is a pointer caps
I can also reproduce this problem by going to Settings > Bluetooth and turning bluetooth Off, then back On. Result is the mouse remains disconnected. - No automatic reconnect to the mouse whether wifi is on or off. - No manual reconnect to the mouse when wifi is on. I'd say the biggest bug is probably the first one. The mouse is already paired there's simply no good reason to not automatically connect; the next big bug is why wifi has to be off to get it to connect.
(In reply to Chris Murphy from comment #3) > I can also reproduce this problem by going to Settings > Bluetooth and > turning bluetooth Off, then back On. Result is the mouse remains > disconnected. > > - No automatic reconnect to the mouse whether wifi is on or off. It's the mouse that's supposed to connect to your computer when it turns on. > - No manual reconnect to the mouse when wifi is on. The hardware, or the driver for the Bluetooth/WiFi chip is likely buggy. > I'd say the biggest bug is probably the first one. The mouse is already > paired there's simply no good reason to not automatically connect; the next > big bug is why wifi has to be off to get it to connect. Let me know when you've fixed the driver problems, I can't spend time trying to debug something that I can't have any hope of fixing at the level gnome-bluetooth is at.
(In reply to Bastien Nocera from comment #4) > (In reply to Chris Murphy from comment #3) > > I can also reproduce this problem by going to Settings > Bluetooth and > > turning bluetooth Off, then back On. Result is the mouse remains > > disconnected. > > > > - No automatic reconnect to the mouse whether wifi is on or off. > > It's the mouse that's supposed to connect to your computer when it turns on. a. When the laptop is put into suspend to ram and wakes up, the mouse works. So the mouse has the ability to see its host vanish for some period of time and reconnect. The problem is clearly with the host state not looking for or connecting the mouse, hence why I have to manually connect 4-5x per day. See related bug https://bugzilla.redhat.com/show_bug.cgi?id=1340659 b. Neither Windows 7, 8, 10, or macOS 10.5 through 10.11 (six years worth of OS's) exhibits this behavior. Reboot, shutdown, and the mouse works and doesn't disconnect 5 times per day. > > > - No manual reconnect to the mouse when wifi is on. > > The hardware, or the driver for the Bluetooth/WiFi chip is likely buggy. > > > I'd say the biggest bug is probably the first one. The mouse is already > > paired there's simply no good reason to not automatically connect; the next > > big bug is why wifi has to be off to get it to connect. > > Let me know when you've fixed the driver problems, I can't spend time trying > to debug something that I can't have any hope of fixing at the level > gnome-bluetooth is at. Well the constant disconnect problems appears to not be hardware or kernel bugs because in the bug I mention earlier, a user reports they don't have these problems on KDE only on GNOME. I haven't tested KDE but it seems somewhere around 8000% easier to just switch DE's for testing, than to figure out how to put everything bluetooth related into some debugging mode to find out what layer the bugs are all in.
(In reply to Chris Murphy from comment #5) > (In reply to Bastien Nocera from comment #4) > > (In reply to Chris Murphy from comment #3) > > > I can also reproduce this problem by going to Settings > Bluetooth and > > > turning bluetooth Off, then back On. Result is the mouse remains > > > disconnected. > > > > > > - No automatic reconnect to the mouse whether wifi is on or off. > > > > It's the mouse that's supposed to connect to your computer when it turns on. > > a. When the laptop is put into suspend to ram and wakes up, the mouse works. > So the mouse has the ability to see its host vanish for some period of time > and reconnect. The problem is clearly with the host state not looking for or > connecting the mouse, hence why I have to manually connect 4-5x per day. See > related bug > https://bugzilla.redhat.com/show_bug.cgi?id=1340659 The host is not supposed to supposed to look for the mouse. The mouse is supposed to connect to the computer, except when pairing. That's the only time the computer will connect to the mouse. > b. Neither Windows 7, 8, 10, or macOS 10.5 through 10.11 (six years worth of > OS's) exhibits this behavior. Reboot, shutdown, and the mouse works and > doesn't disconnect 5 times per day. That's nice. But *even* if it was a problem on the computer side, gnome-bluetooth isn't responsible for that, neither is any other GNOME component. The problem would lie with bluetoothd, or the kernel drivers. > > > - No manual reconnect to the mouse when wifi is on. > > > > The hardware, or the driver for the Bluetooth/WiFi chip is likely buggy. > > > > > > > > > I'd say the biggest bug is probably the first one. The mouse is already > > > paired there's simply no good reason to not automatically connect; the next > > > big bug is why wifi has to be off to get it to connect. > > > > Let me know when you've fixed the driver problems, I can't spend time trying > > to debug something that I can't have any hope of fixing at the level > > gnome-bluetooth is at. > > > Well the constant disconnect problems appears to not be hardware or kernel > bugs because in the bug I mention earlier, a user reports they don't have > these problems on KDE only on GNOME. I haven't tested KDE but it seems > somewhere around 8000% easier to just switch DE's for testing, than to > figure out how to put everything bluetooth related into some debugging mode > to find out what layer the bugs are all in. It's not in GNOME. There are no components in GNOME responsible for connecting to your mouse. This is a system service problem, possibly with root causes in the kernel drivers. Feel free to test under KDE, I don't see how it could work better, unless the mouse expected the device to be connectable, which it shouldn't.
Is this still a problem? Did you test this under KDE?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-bluetooth/issues/31.