Bolt pairing: passkey click sequence displayed with left/right inverted (MX Master 4)

Summary

When pairing a mouse to a Logi Bolt receiver, the passkey click sequence Solaar displays has left and right inverted. Following the on-screen instructions always fails with the unhelpful pairing failed: failed. Clicking the inverse of the displayed sequence pairs successfully on the first try.

Verified on an MX Master 4 with Solaar 1.1.20. The same symptom and packet trace appear in #2534 (MX Master 3S), which was closed without a fix — that reporter gave up and paired from Windows.

Root cause

Both frontends map bit 1 → right:

• solaar/ui/pair_window.py:176
• solaar/cli/pair.py:104

"right" if bit == "1" else "left"

Empirically the device expects bit 1 → left.

Evidence

Two consecutive attempts on the same MX Master 4, same session, same receiver. Only the click polarity differed:

Failing attempt — note ten clean 4E01 bit events and a valid 4E04 terminator, so this is not a timeout or a dropped click; the receiver received ten bits and rejected them:

16:27:27.047  (25) <= w[11 FF 82C1 0100A51372D688D6020A000000000000]   pair, auth=0x02, entropy=0x0A
16:27:27.915  (16) => r[11 FF 4D06 303030393138A51372D688D600000000]   passkey "000918"
16:27:27.916  (16) => r[11 FF 4E00 A51372D688D600000000000000000000]   entry started
16:27:29.920  (16) => r[11 FF 4E01 ...]   \
16:27:30.865  (16) => r[11 FF 4E01 ...]    |
16:27:31.548  (16) => r[11 FF 4E01 ...]    |
16:27:32.058  (16) => r[11 FF 4E01 ...]    |
16:27:32.553  (16) => r[11 FF 4E01 ...]    >  10 bit events
16:27:32.964  (16) => r[11 FF 4E01 ...]    |
16:27:33.355  (16) => r[11 FF 4E01 ...]    |
16:27:33.895  (16) => r[11 FF 4E01 ...]    |
16:27:34.307  (16) => r[11 FF 4E01 ...]    |
16:27:34.689  (16) => r[11 FF 4E01 ...]   /
16:27:35.004  (16) => r[11 FF 4E04 A51372D688D600000000000000000000]   terminator (left+right)
16:27:35.027  (16) => r[11 FF 5402 02A51372D688D6000000000000000000]   status 0x02 = failed

Succeeding attempt, inverted clicks:

16:31:57.696  show passkey: 000923
              ... 10x 4E01, then 4E04 ...
16:32:04.073  (16) => r[11 FF 5402 00A51372D688D6010000000000000000]   status 0x00 = OK, slot 1
16:32:05.144  found new device 1 (B042)
16:32:05.844  success: <Device(1,B042,MX Master 4,CB2BA8D0)>

Cross-check against #2534 (MX Master 3S, Solaar 1.1.13): passkey 303030383938 = "000898" = 1110000010, displayed as right, right, right, left, left, left, left, left, right, left — same mapping, same failure.

Why the error message is useless

4E01 carries no direction byte — every bit event is byte-identical. The receiver cannot report which bit was wrong, only reject the whole passkey at the end as 5402 status 02. So a polarity bug is indistinguishable from a timeout or a mis-click, which is likely why this has been misdiagnosed as "the double press is finicky."

Proposed fix

Swap the mapping in both locations:

"left" if bit == "1" else "right"

Caveat

Confirmed on one device (MX Master 4). The #2534 trace is consistent but that reporter never tried the inverted sequence, so it is not independent confirmation of the fix. Worth verifying on another Bolt mouse before merging, since the keyboard path (authentication & 0x01, numeric passcode) does not use this mapping and is unaffected.

Environment

• Solaar 1.1.20 (Arch Linux, extra/solaar 1.1.20-2)
• Receiver: Bolt, USB 046d:C548
• Device: MX Master 4, WPID B042, HID++ 4.5
• Python 3.14, Wayland (Hyprland)