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 problem

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 journalctl -xe:

bluetoothd[411]: profiles/input/hog-lib.c:set_report_cb() Error setting Report value: Unexpected error code

And this one:

bluetoothd[411]: 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, which is 5.14.14 currently. Affected all all three official mainline kernels:

The situation on LTS kernel linux-lts which 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.

Temporary workarounds

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 command bluetoothctl from the package bluez-utils can 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.

Note: using bluetoothctl in 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 Arch Wiki and requires removing two lines in the /var/lib/bluetooth/adapter_mac/device_mac/info file:

[IdentityResolvingKey]
Key=...

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

Another solution in the wiki just next to the one above is to use 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 dmesg:

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

This is a variation of the above taken from here. It requires bluez-hciconfig which is deprecated. There is also a related bluez-hcitool. The solution suggests the following:

hciconfig hci0 down
rmmod btusb
modprobe btusb
hciconfig hci0 up

Did not work either.

Fail 4: TLP USB autosuspend

Some comments 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 as 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 StackExchange post.

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.

The solution

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 linux-lts54 currently 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!