I consider the trusty Logitech MX Master 3, the computer mouse I use to be a great addition to my toolset. Even though I try to use mouse as little as possible in times when keyboard is the main input source (when I am writing something), the mouse is still very important.
Do not get me wrong, I am probably just another sheep that jumped into bandwagon of the people recommending this mouse, but I would not strive to replace it, as it has all the features I need.
Specifically, the source switch is one such feature. The mouse has a button on it's bottom that lets you switch the source, or the device it is currently connected to. There are three options. Number 1 is for the USB dongle, or Unifying Receiver as Logitech calls it. It is unifying because it let's you connect multiple Logitech devices simultaneously, for instance a mouse and a keyboard. I do not have keyboard yet, as I am still undecided about the ones offered by Logitech.
But I own the mouse and with it, the Unifying Receiver as well. The thing is, the dongle is not plugged in the laptop, but instead, I keep it plugged in the ThinkPad dock, as I explained in the article above. When using dongle (the source 1) that is plugged into laptop or into the dock, the mouse works without any problem, even when dual booting.
The situation changes when I am traveling. I obviously do not take the dock with me, nor the dongle. The mouse has two more sources (numbered 2 and 3), that allow to pair two Bluetooth devices to their respective numbers. So when on the go, I just switch the source from dongle to Bluetooth and everything's fine.
This is especially important when dual booting during the travel, as the source number 3 is paired with another OS. The classic Bluetooth mouse that only has one source is much harder to configure for dual boot.
This fairy tale was going fine for some time, but maybe a two months ago I started experiencing this annoying issue with the Bluetooth. After any kind of resume from suspend or hibernate, or even from restart or cold start, the mouse does connect as it should but is unresponsive immediately. Yesterday I decided I find a solution for good, as it worked without an issue for more than a year already, so it had to be possible.
Symptoms in logs
Apart from the most obvious symptom with unresponsive mouse, there are
other hints that something is amiss. Here are two eye-catching lines from
bluetoothd: profiles/input/hog-lib.c:set_report_cb() Error setting Report value: Unexpected error code
And this one:
bluetoothd: profiles/network/connection.c:connect_cb() connect to 0C:CB:85:02:4E:D4: Host is down (112)
The situation in
dmesg is not happy either. I've found this:
[ 2065.385987] Bluetooth: hci0: Received unexpected HCI Event 00000000 [ 2065.386013] Bluetooth: hci0: unexpected event for opcode 0x0000 [ 2065.431367] Bluetooth: hci0: Received unexpected HCI Event 00000000 [ 2065.622357] Bluetooth: hci0: Received unexpected HCI Event 00000000 [ 2065.633500] Bluetooth: hci0: Received unexpected HCI Event 00000000 [ 2067.354587] Bluetooth: hci0: FW download error recovery failed (-110) [ 2067.355066] Bluetooth: hci0: Hardware error 0x00 [ 2069.488056] Bluetooth: hci0: Controller not accepting commands anymore: ncmd = 0 [ 2069.488072] Bluetooth: hci0: Injecting HCI hardware error event [ 2077.380961] Bluetooth: hci0: Reset after hardware error failed (-110) [ 2077.492030] Bluetooth: hci0: Received unexpected HCI Event 00000000 [ 2079.514574] Bluetooth: hci0: Reading Intel version information failed (-110) [ 2079.514587] Bluetooth: hci0: Intel Read version failed (-110) [ 2079.514585] Bluetooth: hci0: command 0x0c03 tx timeout [ 2081.647859] Bluetooth: hci0: command 0xfc05 tx timeout [ 2081.648039] Bluetooth: hci0: Intel reset sent to retry FW download
And also this:
[ 2082.239431] Bluetooth: hci1: Bootloader revision 0.0 build 26 week 38 2015 [ 2082.240460] Bluetooth: hci1: Device revision is 16 [ 2082.240467] Bluetooth: hci1: Secure boot is enabled [ 2082.240471] Bluetooth: hci1: OTP lock is enabled [ 2082.240474] Bluetooth: hci1: API lock is enabled [ 2082.240476] Bluetooth: hci1: Debug lock is disabled [ 2082.240479] Bluetooth: hci1: Minimum firmware build 1 week 10 2014 [ 2082.248290] Bluetooth: hci1: Found device firmware: intel/ibt-12-16.sfi [ 2084.151749] Bluetooth: hci1: Waiting for firmware download to complete [ 2084.152457] Bluetooth: hci1: Firmware loaded in 1859559 usecs [ 2084.152625] Bluetooth: hci1: Waiting for device to boot [ 2084.165433] Bluetooth: hci1: Device booted in 12616 usecs [ 2084.165710] Bluetooth: hci1: Found Intel DDC parameters: intel/ibt-12-16.ddc [ 2084.168419] Bluetooth: hci1: Applying Intel DDC parameters completed [ 2084.169468] Bluetooth: hci1: Reading supported features failed (-16) [ 2084.170482] Bluetooth: hci1: Firmware revision 0.1 build 212 week 30 2021 [ 2085.744578] logitech-hidpp-device 0005:046D:B023.000D: Device not connected
This line popped up as well:
[ 1338.544489] Bluetooth: hci0: urb 0000000066025a26 failed to resubmit (2)
All of the above could be found on the latest kernel available on Arch,
5.14.14 currently. Affected all all three official mainline
The situation on LTS kernel
currently sits at version
5.10.75-1 is basically identical, which is
quite sad, as I believed the LTS kernel would simply solve this problem.
For the previous two months I had to do the following to get the mouse to work on Bluetooth again.
Option 1: Power cycle the mouse
The most obvious fix is to turn the mouse off and on again via the upper switch on it's bottom. The mouse reconnects and becomes responsive. Annoying to do this many times a day.
Option 2: Cycle the source
Another thing that forces the mouse to reconnect is to press the source button described above exactly three times. Since there are three sources, it ends on the exactly the same source. This is exactly as annoying as the previous option.
Option 3: Gnome Bluetooth GUI
Navigating into Bluetooth settings in Gnome, disconnecting and re-connecting the mouse via GUI switch also does the job. But since it is in GUI, it requires many clicks with touchpad. Absolutely the worst option.
Option 4: bluetoothctl CLI
Obviously, It is possible to use command line to resolve the issue. The
bluetoothctl from the package
do the job:
bluetoothctl -- disconnect MAC_ADDRESS
Which outputs the following:
Attempting to disconnect from E7:B9:C9:15:DF:80 [CHG] Device E7:B9:C9:15:DF:80 ServicesResolved: no Successful disconnected
MAC address of the mouse can be found for instance like this:
bluetoothctl -- devices | grep Master | cut -d' ' -f2
The disconnect seems to be enough, the mouse reconnects itself back and becomes responsive automatically. Not sure what to take out of it.
bluetoothctlin the interactive mode (just running the command) offers completion for commands and MAC addresses too, using it so this way it might be even faster when not inside a script.
What did not work
I've found a reasonable solution, but before I got there, I had to try a few things. For the completeness I include things that I tried that did not work for me.
Fail 1: IdentityResolvingKey
First thing I tried multiple times already is documented in the
and requires removing two lines in the
This is probably the most referred solution to similar problem with Bluetooth mouse, but it did not made any difference for me.
Fail 2: usb_modeswitch
sudo usb_modeswitch -R -v vendor_ID -p product_ID
Fail 3: modprobe btusb
This does not bring the mouse back to responsiveness but it is acutally a
very good way to force logs into
sudo rmmod btusb && sudo modprobe btusb
This was suggested on multiple places, for instance again in the same Bluetooth Arch Wiki page.
Fail 4: hciconfig
hciconfig hci0 down rmmod btusb modprobe btusb hciconfig hci0 up
Did not work either.
Fail 4: TLP USB autosuspend
suggested the USB autosuspend might be the problem as Bluetooth might be
connected internally over USB, which is common. Unfortunately disabling the
tlp service does not change anything.
Using a blacklist or USB_DENYLIST
tlp calls it has no effect.
Fail 5: btusb.enable_autosuspend kernel parameter
Another related solution suggestion that did not work for me is to use the
btusb.enable_autosuspend=n kernel parameter instead. Interesting read can
be found in this
Fail 6: hid2hci
The last obvious solution is to install bluez-hid2hci mentioned multiple times in the already cited Bluetooth Wiki page, for instance here. But this is more just a desperate move and I did not believe it would change anything, which was the case anyway.
I was thankfully able to find a solution to this painful issue in the end.
I have used the older LTS kernel from the AUR package
sitting at version
5.4.155 and let it compile overnight.
This kernel does not appear to do any harm to my workflow and gracefully
solves the Bluetooth mouse issue. With this kernel on ThinkPad T470, the
dmesg is entirely clear without any obvious hiccups, so I might keep it
for a while and see how it goes. Hope that helps!