Repository navigation
Driverless media keys, part 2: the session reads them as inputs (phase 6) #1332
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -555,8 +555,16 @@ So the session emits media keys as Kanata's ordinary outputs: | |
| (system-defined events carry no source device); keyboard backlight (21–23) is in | ||
| the NX table but unmeasured. | ||
|
|
||
| Part 2 adds `1 << 14` to the tap mask so system-defined events become consumer | ||
| inputs to Kanata (consumed only when mapped, hardware repeats swallowed). | ||
| **Part 2 (inputs, 2026-10-20).** The bridge's physical-input rule | ||
| (`physical_input_supported`) admits the same ten consumer codes. The worker adds | ||
| NX_SYSDEFINED (14) to its tap mask; `SessionKeyMap.mediaInput(subtype:data1:)` decodes a | ||
|
Comment on lines
+558
to
+560
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This is a user-visible feature, but the commit updates only developer architecture documents. The published guides still tell users that media and brightness remapping is unavailable in driverless mode ( AGENTS.md reference: AGENTS.md:L382-L383 Useful? React with 👍 / 👎. |
||
| subtype-8 event to Kanata's (usage, value), and the worker sends it as a consumer-page | ||
| input only when the profile maps it — otherwise the event passes through untouched, so | ||
| an unmapped volume key behaves exactly as before. Held media inputs live in their own | ||
| ledger (`mediaInputs`; usage numbers overlap across pages), a release whose press | ||
| predates the tap passes through, and hardware repeats of a held mapped key are | ||
| swallowed because Kanata repeats on its own. Per-device media rules stay impossible: | ||
| system-defined events carry no source device. | ||
|
|
||
| Lowering of *other* intents (computed fall-through under managed Caps, §4.7's | ||
| registry) remains as designed below. | ||
|
|
@@ -615,7 +623,7 @@ until phase 4. | |
| | **3. Claims + engine** — *done (see §4.4a)* | `AdmissionVerdict` (KeyPathRulesCore) and `AdmissionEngine` (AppKit): conflicts from `detectConflicts` attributed to ids, unmet needs, reserved Caps intermediate (moves automatically), another app holding Caps, pack conflicts and requirements. Not called yet. | Golden scenarios match today's detector; attribution to ids; media blocking per backend; intermediate move/block; foreign Caps owner; packs; a fresh profile admits with zero findings against the real bridge. | | ||
| | **4. Callers** — *done 2026-10-19 (4a–4e)* | toggle, rule editor, pack install (conditional preview, see §7), catalog update, save and startup call the engine; `conflictInfo`/`dedupe` divergence removed; the dead `ConflictResolutionDialog` deleted; the dialogs render `Verdict`. | UI tests per caller; pack install preview snapshot; "save reaches a new blocking verdict" logs an error (and the existing test guardrail catches it). | | ||
| | **5. Attribution** — *done 2026-10-19 as phase 4e* | one refusal renderer with the engine's blocking sentences in front of the validator's reason; CLI `doctor` lists verdicts. Line-level attribution from Rust was not needed. | `SessionConfigurationRefusalTests`; lifecycle and CLI tests. | | ||
| | **6. Media keys** — *part 1 done 2026-10-20 (§4.5)* | the bridge's output rule accepts the ten consumer keys the worker posts as system-defined events; the worker posts and releases them. Part 2: the tap reads system-defined events as consumer inputs. | Rust rule tests; `SessionOutputStateTests` media cases; catalog/profile goldens flipped; hardware on the Air. | | ||
| | **6. Media keys** — *done 2026-10-20 (§4.5)* | the ten consumer keys the worker can post are session outputs (part 1) and, read from macOS system-defined events, session inputs (part 2). | Rust rule tests; `SessionOutputStateTests` media output and input cases; `MediaKeyCaptureToSaveTests`; hardware on the Air. | | ||
|
|
||
| Phases 1–3 are additive and can land before #1304–#1309 merge; 4–6 should | ||
| follow them. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When hardware sends NX_KEYTYPE_FAST or NX_KEYTYPE_REWIND (19/20), reversing the entire output table decodes them as newly supported inputs, but
KeyboardCapture.mediaKeyCodeToStringproducesfastforward/rewindandKeyMappingFormatterexplicitly leaves those unchanged because they have no Kanata name. The Mapper therefore cannot generate a validdefsrctoken for these two inputs, despite the bridge admitting their usages; either add a valid lowering or omit them from the input table.Useful? React with 👍 / 👎.