Improve Bluetooth pairing reliability and full HID support for Logitech MX series

[OmarGonD]

Environment

OS: Omarchy 4.0.0 (based on Arch Linux)
Kernel: 7.1.8-arch1-3
BlueZ: 5.87-2
Bluetooth Adapter: Realtek (HCI 5.1)
Interface: hci0
Address: E8:48:B8:C8:20:00

Device: Logitech MX Master 3 (Bluetooth LE)

Issues observed

The MX Master 3 frequently does not appear with a normal bluetoothctl scan on. It only becomes visible when forcing LE discovery (btmgmt find -l, scan le, or hcitool lescan).
The device MAC address can change slightly between pairing attempts (e.g. EF:4A:2C:56:81:7B → EF:4A:2C:56:81:7C).
After pairing, the connection often drops immediately with messages such as:
LE.Disconnected - org.bluez.Reason.Remote, Connection terminated by remote user
org.bluez.Reason.Timeout / Unspecified

Once connected, mouse clicks work correctly, but the scroll wheel does not respond.

Found a reddit post from a user with the same issue:

https://www.reddit.com/r/omarchy/comments/1r3l3kr/mx_master_bluetooth_fails_to_connect_after_resume/

Workarounds required

Full removal of previous pairing data (bluetoothctl remove + deleting the corresponding folder under /var/lib/bluetooth/)
Restarting bluetooth.service
Setting IdleTimeout=0 and UserspaceHID=true in /etc/bluetooth/input.conf
Strict order of trust → pair → connect while the device was actively advertising
Forcing LE scan with btmgmt find -l

Suggestion
Logitech MX series devices are very common. It would be a significant improvement if Omarchy could provide better out-of-the-box support for them by:

Improving automatic LE discovery
Making the pairing/reconnection flow more robust
Ensuring full HID report handling so that the scroll wheel and extra buttons work correctly after pairing

Thanks!

[OmarGonD]

Omarchy currently ships no /etc/bluetooth/ overrides.
Even with BlueZ 5.87 (which defaults UserspaceHID=true and IdleTimeout=0), the MX Master 3 still requires a forced LE scan + clean remove of the device directory under /var/lib/bluetooth/ and still loses the scroll wheel after pairing.

[zigmoo]

Adding a closely related data point from Omarchy 4.0.2-1 (linux 7.1.9.arch1-2, BlueZ 5.87-2) on a Framework 16 with a MediaTek 0e8d:0717 Bluetooth controller.

I can reproduce the unwanted disconnect/refusal-to-reconnect behavior with two Logitech MX devices: an MX Master 3 and an MX Anywhere 3S. Both pair, bond, and trust successfully and initially work. After an idle period they disconnect and do not reconnect through the normal panel flow. While disconnected, both remain visible and advertise at strong RSSI. A Keychron K10 HE Bluetooth keyboard and Bose NC700 remain usable on the same controller, so this is not a blanket Bluetooth outage.

There is also an Omarchy-specific clue: with the Bluetooth panel closed, bluetoothctl show remains at Discovering: yes. omarchy-shell logged the following within seconds of connecting each MX device:

Failed to stop discovery ... "No discovery started"

Restarting the Omarchy shell changed the Quickshell PID but did not clear Discovering: yes. This overlaps the continuous/stuck-discovery behavior in #8614 and may be relevant to why the MX links fail to recover. The kernel also repeatedly reports Bluetooth: hci0: ACL packet for unknown connection handle 3837, although I have not yet mapped that handle to either mouse. There is no local hog-lib / ATT “Unlikely Error” signature.

One testing caveat: omarchy restart bluetooth in 4.0.2-1 did not perform a daemon restart here. The installed script (identical to current upstream) only runs rfkill unblock bluetooth; bluetooth.service retained the same PID and start timestamp. Therefore I have not yet tested a real bluetoothd/controller restart.

This is not identical to the original report: my devices are genuinely bonded, I have not observed the scroll-wheel failure, and the drops happen after idle rather than necessarily immediately after pairing. But the core MX-series BLE disconnect/reconnection failure is reproduced across a second adapter family and a second MX model on the same Omarchy/BlueZ generation. I am capturing the next recurrence with btmon to identify the initiating HCI disconnect reason.

[garymeyerca]

Adding another successful initial-pairing data point for an MX Master 3 on Omarchy.

Environment:

• Omarchy: 4.0.0.r2083.gd504061-1
• Kernel: 7.2.3-arch1-3
• BlueZ: 5.87-2

The mouse was advertising with a strong signal (roughly -43 to -51 dBm), but initial bluetoothctl pair attempts did not complete. Privileged btmgmt find -l confirmed that the mouse was advertising over LE. At one point it appeared in that scan but was unavailable to bluetoothctl; starting scan le in an interactive bluetoothctl session made it available there again.

After putting the mouse in pairing mode by holding its underside Easy-Switch button until the channel light blinked rapidly, the successful sequence in that interactive session was:

scan le
# Wait for MX Master 3 to appear; use its discovered address below.
trust <mouse-address>
pair <mouse-address>

BlueZ then reported Trusted: yes, Connected: yes, Bonded: yes, ServicesResolved: yes, Paired: yes, and Pairing successful. The mouse was working immediately; a separate connect command was unnecessary in this attempt. We then ended our discovery session with scan off and quit.

No Bluetooth service restart, manual pairing-directory deletion, or input.conf changes were needed. The installed input.conf already documents defaults of IdleTimeout=0 and UserspaceHID=true.

Trusting before pairing coincided with success, but this was not a controlled test separating command order from pairing-mode timing and the active LE scan. This confirms initial pairing and basic operation only; scroll/extra-button behavior and reconnection after idle or suspend have not been separately verified.

[lukejmorrison]

Datapoint: Logitech MX Anywhere 3S on Omarchy 4.0.3-1, same idle-drop / refusal-to-reconnect behaviour zigmoo described, on a third adapter family.

System

Board	ASUS X99-E WS/USB 3.1, Intel i7-5930K
Omarchy	4.0.3-1
Hyprland / quickshell	0.56.2-2 / 0.3.1-1
BlueZ	5.87-2
Running kernel	7.1.9-arch1-2 (package is 7.2.3.arch1-3; no reboot onto it yet)
Adapter	Intel AX200 8087:0029, firmware intel/ibt-20-1-3.sfi (193-33.24)
Mouse	MX Anywhere 3S, HOG, PID 046d:b037, random addr DD:92:1D:04:06:C1, HID++ 4.5, battery 55%

Keyboard is a Keychron V6 Max on 2.4 GHz Keychron Link and does not drop. Audio/A2DP is not involved. Only the MX BLE mouse dies.

No /etc/bluetooth overrides. IdleTimeout / UserspaceHID / ReconnectUUIDs are still the commented BlueZ defaults (ReconnectUUIDs audio-only).

Symptom

Bonds and works, then after idle (often 30–80 minutes; overnight it stayed down) it is still Paired/Bonded/Trusted but Connected: no. Hyprland loses logitech-mx-anywhere-3s. Clicks/scroll do nothing until the adapter is power-cycled.

Same Omarchy-side clue as zigmoo:

• Bluetooth panel closed
• bluetoothctl show / Adapter1.Discovering stayed yes
• StopDiscovery from another client: No discovery started, Discovering stayed true

Adapter power-cycle (omarchy bluetooth power off / on) clears the stuck scan. Then omarchy bluetooth device connect …:C1 attaches immediately if the mouse is awake. If it is still asleep (no RSSI), connect times out until a physical click / short Easy-Switch press. Long-press is a new pair and mints a new MAC; that is a separate footgun.

bluetoothd on the two recoveries today:

Wrong size of start discovery return parameters

This boot also had one HOG ATT Unlikely Error burst (hog-lib.c:set_report_cb / ccc_read_cb) at a reconnect, then HID++ came back.

HID++ device connected this boot (every line is a drop + reattach, not a reboot):

Sep 08 07:59:01 (boot)
Sep 08 13:13:15
Sep 08 17:03:10
Sep 09 07:30:38, 09:31:44, 13:00:27
Sep 09 18:29:12, 19:01:09, 19:41:18, 20:34:28, 21:56:23
Sep 10 07:07:28, 08:04:52, 08:09:30

Fuller write-up with dbus/kernel snippets is on #10818 (Bluetooth panel / leaked LE discovery session blocking HOG reconnect). #10142 / #10176 look related for the panel retry; this box did not have the panel open, so a foreign discovery session (Chromium is running here) is also in play, as noted on #10818.

Happy to grab btmon on the next drop.