Bluetooth mouse disconnects often after Plasma 5.23 upgrade

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


  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?

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 :


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


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:


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:

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(":", "_")
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...")
        except dbus.exceptions.DBusException:

*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?

I don’t have a device to test it on. If anyone else could try it, it would be much appreciated.

I’ve tested the script : the detection is okay when the laptop resume from sleep. I can this the output
Mouse connected, attempt to pair...
but the cursor is still stuck.

It’s not working for me.

This doesn’t work for me either.

I saw a new aur package called rebind devices which seems worth trying. It’s a systemd service to automatically reset devices when resuming from sleep.

If you decide testing it, let us know how it went.

I’ve tried the package but I can’t figure out how I can retrieve the BUS ID for a bluetooth mouse :confused:

I’ve tried also to switch to 5.15 kernel (some users report that it can solve bluetooth connection with Intel AX200 Wifi / bluetooth card : Bluetooth of my Logitech mouse sometimes not-working - #7 by Firestar) but no changes.

I’m using 5.10 kernel normally.

maybe it’s time to update the kernel first before ongoing any troubleshooting. it’s a good choice to update to the newest kernel actually, there are too many changes under the hood.

Ok I’ll stay with kernel 5.15.12 (no RT) for further troubleshooting

Have you tried running inxi -Fxz?