Files

Jake 528facfab0 fix(rb-12): hotkey device filter consults configured HotkeyCombo

try_attach_device was rejecting any device that did not report KEY_A or
KEY_R — a leftover heuristic from the whisper-overlay seed. A user whose
binding was anything else (Ctrl+Shift+D is a common default) would see
no hotkey events from that device even though it supports the key.

Replace the hard-coded check with device_supports_combo(supported,
combo), a pure helper that reads the configured trigger key code from
the HotkeyCombo snapshot. Snapshot is taken from hotkey_rx.borrow()
before opening the device; an unconfigured or shutting-down listener
short-circuits to a non-attach.

Four regression tests in linux::tests cover: supported+D → attach,
unsupported → reject, no reported keys → reject, and the explicit
non-A/non-R case that demonstrates the bug.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-04-22 10:18:54 +01:00

2.0 KiB

Raw Blame History

RB-12 MAJOR: hotkey device filtering hard-codes KEY_A / KEY_R

Severity: MAJOR Path: crates/hotkey/src/linux.rs:236-241 Source: 2026-04-22 code review Labels: release-blocker, major, hotkey, correctness Status: RESOLVED (2026-04-22)

Resolution

Extracted device_supports_combo(supported, combo) -> bool as a pure helper. try_attach_device now snapshots the current HotkeyCombo from hotkey_rx (returning early with false if the listener is unconfigured) and uses the helper to filter devices by the configured trigger key.

Tests in crates/hotkey/src/linux.rs (linux::tests):

attaches_when_device_supports_configured_trigger
rejects_when_device_lacks_configured_trigger
rejects_when_device_reports_no_keys
attaches_for_non_a_non_r_trigger (direct regression)

Manual verification of the Ctrl+Shift+D binding in Settings remains on the ship-gate checklist — code path is correct; runtime GUI check is deferred.

Problem

try_attach_device claims to check whether an input device supports the configured hotkey's key, but the implementation tests for hard-coded KEY_A or KEY_R instead of consulting the actual HotkeyCombo that was configured. Hotkeys bound to any other key (which is most of them) can be silently skipped even when the device supports them.

This is a correctness bug in a user-facing feature. A user who binds Kon to Ctrl+Shift+D and sees "no hotkey fires" has no obvious path to diagnose it.

Acceptance

Device attachment consults the actual configured HotkeyCombo.trigger key code.
Regression test: try_attach_device called with a mock device that supports KEY_D attaches when the configured hotkey's trigger is D, does not attach when the trigger is a key the device doesn't support.
Manual verification: bind Ctrl+Shift+D in Settings, confirm it fires in a running Kon.

Fix scope

Small. Replace the hard-coded constants with a lookup from the passed-in HotkeyCombo.

Dependencies

None — standalone fix.

2.0 KiB Raw Blame History