# 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](../code-review-2026-04-22.md) **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.