Summary
In the Bolt pairing flow, the passkey entry method shown to the user is chosen only from the discovery authentication byte:
// crates/openlogi-hid/src/pairing.rs — Notification::Passkey handler
let method = match pairing_auth {
Some(auth) if auth & 0x01 != 0 => PasskeyMethod::Keyboard(digits),
_ => PasskeyMethod::Pointer { clicks: passkey_to_clicks(value), passkey: digits },
};If a keyboard-like device is discovered but its pairing_auth byte does not carry bit 0x01, the session may still have been opened expecting keyboard entropy, yet the UI falls back to the pointer (click-sequence) method. The user is then shown click instructions for what is actually a keyboard passkey, the receiver keeps waiting for typed digits, and pairing times out.
Raised by Greptile on #381. This is pre-existing behavior — #381 (a refactor sweep) only tightened the passkey digit validation around this block; it did not introduce or change the method-selection condition, so fixing it there would be out of scope.
Open question / needs hardware
Whether pairing_auth & 0x01 is genuinely unreliable for keyboard-like Bolt devices, or whether the discovered kind should be consulted as a fallback, needs verification against real Bolt keyboards + receiver — the maintainer's hardware. If confirmed, the fix is to fold the discovered kind into the method decision (e.g. treat keyboard-like kinds as keyboard entry when the auth bit is ambiguous).
Summary
In the Bolt pairing flow, the passkey entry method shown to the user is chosen only from the discovery authentication byte:
If a keyboard-like device is discovered but its
pairing_authbyte does not carry bit0x01, the session may still have been opened expecting keyboard entropy, yet the UI falls back to the pointer (click-sequence) method. The user is then shown click instructions for what is actually a keyboard passkey, the receiver keeps waiting for typed digits, and pairing times out.Raised by Greptile on #381. This is pre-existing behavior — #381 (a refactor sweep) only tightened the passkey digit validation around this block; it did not introduce or change the method-selection condition, so fixing it there would be out of scope.
Open question / needs hardware
Whether
pairing_auth & 0x01is genuinely unreliable for keyboard-like Bolt devices, or whether the discoveredkindshould be consulted as a fallback, needs verification against real Bolt keyboards + receiver — the maintainer's hardware. If confirmed, the fix is to fold the discoveredkindinto the method decision (e.g. treat keyboard-like kinds as keyboard entry when the auth bit is ambiguous).