Bluetooth mouse disconnects often after Plasma 5.23 upgrade

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:

kwin_x11	qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 55641, resource id: 33557103, major code: 18 (ChangeProperty), minor code: 0
bluetoothd	Disconnected from D-Bus. Exiting.
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSource/ldac
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSink/aptx_hd
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSource/aptx_hd
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSink/aptx
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSource/aptx
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSource/aac
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSink/sbc
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSource/sbc
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSink/sbc_xq
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSource/sbc_xq
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSource/faststream
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSource/faststream_duplex
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSource/aptx_ll_1
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSource/aptx_ll_0
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_1
bluetoothd	Endpoint unregistered: sender=:1.79 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_0
dbus-daemon	[system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service' requested by ':1.79' (uid=1000 pid=1211 comm="/usr/bin/pipewire-media-session ")
upower.service	invalid cast from 'GDBusObjectProxy' to 'UpDevice'
upower.service	up_daemon_device_removed_cb: assertion 'UP_IS_DEVICE (device)' failed
upower.service	invalid cast from 'GDBusObjectProxy' to 'UpDevice'
upower.service	up_daemon_device_removed_cb: assertion 'UP_IS_DEVICE (device)' failed
plasmashell	file:///usr/share/plasma/plasmoids/org.kde.plasma.bluetooth/contents/ui/logic.js:22: TypeError: Cannot read property 'devices' of undefined
kded5	bluedevil: Bluetooth operational changed false
plasmashell	file:///usr/share/plasma/plasmoids/org.kde.plasma.bluetooth/contents/ui/logic.js:22: TypeError: Cannot read property 'devices' of undefined

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

This is very interesting, was this happening to you before the most recent stable update?

Today it seems to be behaving better for me (not a very scientific assessment) so I’ll continue to see if there are further disconnections.

EDIT looks like I’m seeing a few more of those same bluetooth undefined lines today although it’s fewer than previously.

Nope. I never had issues with MX and BT connectivity until yesterday’s update.

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

exact same problem here. MX Master. still there when going back to kernel 5.14.

Same here.

It started happening more frequently again in the past couple days. Those log lines keep showing up when it does happen.

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?

It happens to my other Bluetooth devices at the same time however.

When the mouse dies, my Bluetooth keyboard and earbuds also disconnect completely. It’s as if the entire Bluetooth stack just crashes momentarily.

I’m starting to notice a pattern (not 100%) of the bluetooth dying when a new instance of something running Chromium starts.

Try seeing if this kills your bluetooth:

  1. Build and install this AUR package: AUR (en) - notion-app-enhanced
  2. Run the application
  3. Check to see if bluetooth disconnects

OR

  1. 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.

Has anyone here tried this?

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.

I didn’t succeeded on my side to reproduce this problem starting a new Chromium instance

I’ve tried it : the mouse seems to be connected but the cursor didn’t react when I move the mouse physically

image

I still need to power off and power on the mouse again and, then, the mouse is working correctly

similar issue :point_down:

Maybe you need to adjust “BT auto power-on after boot/resume policy” settings, per archwiki.

sudo nano /etc/bluetooth/main.conf

Uncomment and change the line:

[Policy]
AutoEnable=true

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.

The script is this one:

#!/usr/bin/python
 
import dbus
import dbus.mainloop.glib
from gi.repository import GLib
 
adapter = "hci0"
device = "xx:xx:xx:xx:xx:xx"
device_path = '/org/bluez/' + adapter + "/dev_" + device.replace(":", "_")
 
dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
system_bus = dbus.SystemBus()
device_object = system_bus.get_object('org.bluez', device_path)
device_interface = dbus.Interface(device_object, 'org.bluez.Device1')
 
def device_info(_arg0, event, _arg2):
    if event.get("Connected"):
        print("Mouse connected, attempt to pair...")
        try:
            device_interface.Pair()
        except dbus.exceptions.DBusException:
            pass
 
system_bus.add_signal_receiver(
    device_info,
    dbus_interface='org.freedesktop.DBus.Properties',
    signal_name="PropertiesChanged",
    arg0='org.bluez.Device1')
 
GLib.MainLoop().run()

*Arch’s collaborator

I am sharing this here hoping someone might come out with a better idea.

EDIT: it doesn’t seem to work.

Does it work?