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.