After upgrading to Plasma 5.23, I’ve noticed an issue where my Logitech MX Master 3 mouse begins experiencing bluetooth issues and can only be remedied by turning the mouse off and on again.
When this happens, the following is displayed in the logs:
The last line is repeated numerous times in the log, one after the other. Interestingly enough, I have another Logitech keyboard paired at the same time and that one does not appear to drop in the same way that the mouse does. Neither keyboard nor mouse had an issue prior to the 5.23 upgrade and I’ve kept the same kernel from before the update as well (5.14)
Same problem here with Logitech MX Master 3. Tried with kernels 5.13, 5.14 and 5.15. To make mouse work again after boot or waking out of suspend, I need to disonnect/connect or turn off/on mouse.
$ inxi -E
Bluetooth: Device-1: Intel AX200 Bluetooth type: USB driver: btusb
Report: rfkill ID: hci0 state: up address: see --recommends
I’m experiencing the same issue with my MX Master 1 since updating to 5.23. I need to manually disconnect/reconnect the mouse after logging in for it to work. First time I’ve had problems. My BT ThinkPad keyboard works as before. I’ve tried a few different kernels but no luck so far.
$ inxi -E
Bluetooth: Device-1: Intel Bluetooth wireless interface type: USB driver: btusb
Report: rfkill ID: hci0 state: up address: see --recommends
Same problem here : I have to power off / power on the mouse after the first boot or after each sleep / resume.
Bluetooth is well connected (I see it on the bluetooth indicator) and the light indicator on the mouse confirm that bluetooth is connected.
Maybe it’s not relative to bluetooth but directly to the mouse controller / settings managed by KDE?
Open Konsole and launch Chromium from it: chromium
Very odd. The good news is it seems reproducible for me on an X1 Carbon Gen 9 and Chromium 96.0.4664.93. The issue does not occur when launching Google Chrome however.
Quoting:
Problems with all BLE devices on kernel 5.9+
Starting with v5.9, the kernel Bluetooth stack tries to use link-layer privacy on BLE connections. If the device works after pairing but does not survive a reboot or suspend, it is probably because of this.
To workaround [2] this issue, open /var/lib/bluetooth/adapter_mac/device_mac/info , remove the following lines, and restart bluetooth.service :
[IdentityResolvingKey]
Key=...
It was supposed to be fixed, but it might be a kernel regression.
I’ll need to try that at some point but that might be a separate issue. In my case, the bluetooth stack seems to sometimes crash and it seems to be reproducible with Chromium.
Thanks @clmbtti, but still no change.
The mouse is well connected but cursor still didn’t react after a reboot or a standby wake up without a power off / power on.
I am going to ping @cscs to help us on this one and improve upon on the script below.
Thanks to Google Translate, I was reading Felix*'s blog on an issue he was having in 2019 with bluez. He noticed the same issue of the topic; if he manually sent a pair command using bluetoothctl, the mouse would stay (re)connected for a while, but eventually would disconnect. He then wrote a python script he kept running in background.