Bluetooth connection to mouse sometimes doesn’t work

Might be coincidence, but since the latest update I have the issue that after some time the Bluetooth connection to the mouse doesn’t work. I first thought it might be related to the monitor going to standby since the Bluetooth USB adapter sits in a USB port in the monitor, but the Bluetooth keyboard still works.
Actually, I can use the keyboard to wake the screen. Then use it to go to Bluetooth settings and re-connect the mouse. This, weirdly enough, will restart Bluetooth and disconnect the keyboard. But with the mouse working I can then reconnect the keyboard.

dmesg shows:

[Aug26 16:38] Bluetooth: hci1: Opcode 0x200c failed: -110
[  +0,000016] Bluetooth: hci1: Unable to disable scanning: -110
[  +0,000004] Bluetooth: hci1: disable scanning failed: -110
[  +0,000002] Bluetooth: hci1: start background scanning failed: -110
[  +0,000006] Bluetooth: hci1: command 0x200c tx timeout
[  +0,000008] Bluetooth: hci1: Resetting usb device.
[  +0,154258] usb 1-5.1.1: reset full-speed USB device number 8 using xhci_hcd
[  +0,119849] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=dfc6 lmp_ver=0a lmp_subver=d922
[  +0,208129] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761
[  +0,000937] Bluetooth: hci0: RTL: rom_version status=0 version=1
[  +0,001062] Bluetooth: hci0: RTL: btrtl_initialize: key id 0
[  +0,000013] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin
[  +0,000597] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin
[  +0,000113] Bluetooth: hci0: RTL: cfg_sz 6, total sz 30210
[  +0,152217] Bluetooth: hci0: RTL: fw version 0xdfc6d922
[  +0,067205] Bluetooth: MGMT ver 1.23
[  +0,555327] input: iClever Mouse 5.0 as /devices/virtual/misc/uhid/0005:000E:3412.0006/input/input29
[  +0,000397] hid-generic 0005:000E:3412.0006: input,hidraw1: BLUETOOTH HID v5.06 Mouse [iClever Mouse 5.0] on 04:42:1a:48:8e:22
[ +16,736640] input: ERGO K860 Keyboard as /devices/virtual/misc/uhid/0005:046D:B359.0007/input/input30
[  +0,043179] input: ERGO K860 Mouse as /devices/virtual/misc/uhid/0005:046D:B359.0007/input/input31
[  +0,000232] hid-generic 0005:046D:B359.0007: input,hidraw2: BLUETOOTH HID v0.10 Keyboard [ERGO K860] on 04:42:1a:48:8e:22

System details
❯ inxi -bEJ 
System: 
  Host: private Kernel: 7.2.0--1-MANJARO arch: x86_64 bits: 64 
  Desktop: KDE Plasma v: 6.7.4 Distro: Manjaro Linux 
Machine: 
  Type: Desktop Mobo: Micro-Star model: PRO Z690-A DDR4(MS-7D25) v: 1.0 
    serial: <superuser required> Firmware: UEFI vendor: American Megatrends LLC. 
    v: 1.L0 date: 04/16/2025 
CPU: 
  Info: 6-core 12th Gen Intel Core i5-12400F \[MT MCP\] speed (MHz): avg: 800 
    min/max: 800/4400 
Graphics: 
  Device-1: Advanced Micro Devices \[AMD/ATI\] Navi 22 \[Radeon RX 6700/6700 
    XT/6750 XT / 6800M/6850M XT\] driver: amdgpu v: kernel 
  Display: wayland server: X.org v: 1.21.1.24 with: Xwayland v: 24.1.13 
    compositor: kwin_wayland driver: X: loaded: amdgpu 
    unloaded: modesetting,radeon dri: radeonsi gpu: amdgpu 
    resolution: 3440x1440\~60Hz 
  API: OpenGL v: 4.6 vendor: amd mesa v: 26.1.7-arch1.1 renderer: AMD 
    Radeon RX 6700 XT (radeonsi navi22 ACO DRM 3.64 7.2.0--1-MANJARO) 
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo 
    de: kscreen-console,kscreen-doctor gpu: corectrl wl: wayland-info 
    x11: xdpyinfo, xprop, xrandr 
Network: 
  Device-1: Intel Ethernet I225-V driver: igc 
  Device-2: AVM GmbH FRITZ!WLAN AC 860 driver: mt76x2u type: USB 
Bluetooth: 
  Device-1: ASUSTek ASUS USB-BT500 driver: btusb type: USB 
  Report: rfkill ID: hci0 state: up address: see --recommends 
Drives: 
  Local Storage: total: 4.17 TiB used: 1.15 TiB (27.4%) 
USB: 
  Hub-1: 1-0:1 info: hi-speed hub with single TT ports: 16 rev: 2.0 
  Device-1: 1-2:2 info: Micro Star MYSTIC LIGHT type: HID rev: 1.1 
  Hub-2: 1-5:3 info: Genesys Logic Hub ports: 4 rev: 2.0 
  Hub-3: 1-5.1:5 info: Genesys Logic Hub ports: 2 rev: 2.1 
  Device-1: 1-5.1.1:8 info: ASUSTek ASUS USB-BT500 type: bluetooth rev: 1.1 
  Device-2: 1-5.2:9 info: AVM GmbH FRITZ!WLAN AC 860 type: Network rev: 2.0 
  Device-3: 1-12:4 info: Canon CanoScan LiDE 210 type: <vendor specific> 
    rev: 2.0 
  Hub-4: 1-13:6 info: Genesys Logic Hub ports: 4 rev: 2.0 
  Hub-5: 2-0:1 info: super-speed hub ports: 9 rev: 3.1 
  Hub-6: 2-4:2 info: Genesys Logic GL3523 Hub ports: 2 rev: 3.2 
  Device-1: 2-7:3 info: Seiko Epson ES-580W type: <vendor specific> rev: 3.2 
Info: 
  Memory: total: 32 GiB available: 31.13 GiB used: 5.96 GiB (19.2%) 
  Processes: 379 Uptime: 6h 42m Shell: Zsh inxi: 3.3.41

Moderator Edit: Fixed formatting

Try using the last kernel from the 6th series

No issues with Linux 6.18.45-1.
So I need to report elsewhere, I guess?

If linux618 works, I’d think you will be safe to use that until the later Kernel is updated, which might contain a fix. :wink:

Appears I did not wait long enough. After an hour or so away from the computer I again have seen the behavior I reported originally. So different kernel does not make any difference, unfortunately.

It may after all be an issue related to returning from a sleep state. With the other kernels, does the issue similarly raise it’s head after a period away from the computer?


These few posts have been moved to a dedicated topic as this may deserve deeper scrutiny than the Announcement topic is intended for.

Sometimes un-pairing the mouse and re-pairing will fix this issue. Sometimes!

Yes.
As I wrote originally, I thought it might have been connected to the monitor going to sleep. However, it’s apparently not the monitor itself. I am not sure, which other power savings kick in later. I would have thought none. Here are my settings:

I do have a workaround, as described. It’s just annoying, and I’d like to understand what’s going on.


Mod edit:- Please avoid consecutive posts. Instead, edit your previous post to add more content (if there are no intervening posts).

It’s also possible there may be related BIOS settings that contribute; but, every BIOS is different.

This, at least, is a possible avenue of investigation. There have been other cases of an apparent loss of bluetooth functionality when returning from sleep.

As I write, I’m uncertain if they were resolved, however I seem to recall that in at least one instance switching back to kernel 6.18 (LTS) provided some relief from the annoyance.

Yeah, I had issues with the computer not coming back from sleep two years ago or so, which I could fix with a BIOS upgrade. However, just one of two Bluetooth devices loosing connection doesn’t sound like BIOS to me. Wouldn’t that have a more global effect? Also, I have not changed any BIOS settings recently.

I have seen this issue with kernel 7.2.0-1 as well as 6.18.45-1, which is the LTS version. So no, I don’t think it is related to the kernel.

We can exclude the kernel regression then. We could try disabling the scan / refresh:

In /etc/bluetooth/main.conf add or enable the two lines. Save and reload the daemons / restart bluetooth after. The lines are to be add in the General section

TargetedScan=false
RefreshDiscovery=false

This settting didn’t change anything.

Here is the dmesg output. I stopped using the computer around 21:20. Then woke it up around 22:25.
I tried to use the mouse first. Unsuccessfully. Then used the keyboard to wake it and opened the Bluetooth settings to re-connect the mouse. Which, again, restarted the whole Bluetooth service.

[Aug27 21:15] x86/split lock detection: #AC: IPC:CSteamEngin/2460 took a split_lock trap at address: 0xf3af0cea
[Aug27 22:00] EXT4-fs (sda2): mounted filesystem 8077cafe-145e-4505-a3f3-703851ac6ebe r/w with ordered data mode. Quota mode: none.
[  +0,071929] EXT4-fs (sda2): unmounting filesystem 8077cafe-145e-4505-a3f3-703851ac6ebe.
[Aug27 22:06] usb 1-5.4: USB disconnect, device number 9
[Aug27 22:29] amdgpu 0000:03:00.0: [drm] User-defined mode not supported: "3440x1440": 60 419154 3440 3688 4064 4688 1440 1441 1444 1490 0x20 0x6
[Aug27 22:30] Bluetooth: hci0: Opcode 0x200c failed: -110
[  +0,000015] Bluetooth: hci0: Unable to disable scanning: -110
[  +0,000004] Bluetooth: hci0: disable scanning failed: -110
[  +0,000002] Bluetooth: hci0: start background scanning failed: -110
[  +0,000038] Bluetooth: hci0: command 0x200c tx timeout
[  +0,000010] Bluetooth: hci0: Resetting usb device.
[  +0,165189] usb 1-5.1.1: reset full-speed USB device number 8 using xhci_hcd
[  +0,120220] Bluetooth: hci1: RTL: examining hci_ver=0a hci_rev=dfc6 lmp_ver=0a lmp_subver=d922
[  +0,203997] Bluetooth: hci1: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761
[  +0,000997] Bluetooth: hci1: RTL: rom_version status=0 version=1
[  +0,000999] Bluetooth: hci1: RTL: btrtl_initialize: key id 0
[  +0,000005] Bluetooth: hci1: RTL: loading rtl_bt/rtl8761bu_fw.bin
[  +0,000623] Bluetooth: hci1: RTL: loading rtl_bt/rtl8761bu_config.bin
[  +0,000084] Bluetooth: hci1: RTL: cfg_sz 6, total sz 30210
[  +0,148504] Bluetooth: hci1: RTL: fw version 0xdfc6d922
[  +0,069182] Bluetooth: MGMT ver 1.23
[  +5,279931] input: iClever Mouse 5.0 as /devices/virtual/misc/uhid/0005:000E:3412.0006/input/input26
[  +0,000488] hid-generic 0005:000E:3412.0006: input,hidraw3: BLUETOOTH HID v5.06 Mouse [iClever Mouse 5.0] on 04:42:1a:48:8e:22
[  +5,848925] input: ERGO K860 Keyboard as /devices/virtual/misc/uhid/0005:046D:B359.0007/input/input27
[  +0,048895] input: ERGO K860 Mouse as /devices/virtual/misc/uhid/0005:046D:B359.0007/input/input28
[  +0,001002] hid-generic 0005:046D:B359.0007: input,hidraw4: BLUETOOTH HID v0.10 Keyboard [ERGO K860] on 04:42:1a:48:8e:22

Your dmesg output suggests the kernel loses connection to the realtek RTL8761BU bluetooth dongle as evidenced by the -110 ETIMEDOUT kernel error. This is probably due to your monitor sleeping and disrupting the USB hub power state. This then likely triggers a firmware/driver bug (for example: Linux-Kernel Archive: Re: [RFC PATCH 0/2] Bluetooth: detect broken extended scan instead of guessing by chip id). The monitor detects HID activity on the keyboard which triggers it to wake despite the BT controller not currently communicating with the kernel. Once the monitor is powered back up the kernel eventually sees it but the dongle doesn’t respond to HCI command so btusb resets and the BT adapter re-enumerates which is why you see increasing number of hci0hci1. Restarting bluetooth effectively wipes the slate clean and starts the process over again which then works.

The real answer is to plug your bluetooth dongle into a USB port directly on your motherboard (or as close to it as possible). Then try it at some point in the future to see if the issue is resolved, but piggybacking controllers is never really a good idea and will almost always result in some unexpected behaviour.

Notwithstanding that @bananamangodog has a very valid point, we could try one last hack :

/etc/bluetooth/main.conf > search for and enable #ControllerMode = dual modifying dual which is default to bredr(classic connection). And last but not least

systemctl daemon-reload
systemctl restart bluetooth

https://www.mathworks.com/help/bluetooth/gs/comparison-of-bluetooth-bredr-and-bluetooth-le.html

Thanks for your input, @bananamangodog. I might change the dongle just for my peace of mind. (And also to check if the issues persists.)
However, I am still confused why it did work for many months and suddenly stopped working properly after the update. It’s … suspicious.

Also, from the timing, I think the Bluetooth errors only showed up after I navigated to the Bluetooth settings using the keyboard and tried to reconnect the mouse. Since I can use the keyboard, I think the BT controller must have been communicating with the kernel, right?

I’ll try @libertypo’s suggestion in a moment.

Your initial description is likely the key to a plausible explanation - I am thinking that power management is the likely cause.

The upstream kernel development may introduce small changes in power management and the signal path in the kernel driver module system.

When you make the bluetooth connection depending on the monitor - by using the monitors USB hub - you may have introduced a loop or a race condition.

The most viable option will be to remove the bluetooth adapters dependency on the monitors USB hub - simply move it to the physical computer instead.

Quite possibly that kernel regression bug I linked to. It was backported to 6.18, 7.1, and 7.2 but has been identified so should eventually be fixed at some point in the future. Since patches aren’t backported to ALL versions of a kernel, you likely got an update with the backported bug in it.

Both were communicating with the kernel, but something gets messed up causing some kind of communication issue for the mouse. The kernel rightly requests a reset but it doesn’t quite completely fix the issue until you manually disable bluetooth and reenable it again.

I don’t think this will work given the communication issues but no harm in trying.

It will be a trade off anyway if it works, LE devices won’t connect. :man_shrugging:

@libertypo’s suggestion didn’t help.
Moving the Bluetooth dongle to a USB port directly on the MB did fix it, though.

Thank you to everyone helping with ideas! I appreciate the effort.

P.S. Nope, the issue still occurs, if I wait long enough. Let’s hope some future change will fix it.