torjus/nixos
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Releases Activity

docs: clarify keyboard issue is not timing-related
All checks were successful
Run nix flake check / flake-check (push) Successful in 1m46s
Details
Periodic flake update / flake-update (push) Successful in 4m18s
Details

Browse Source 
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Torjus Håkestad
2026-03-06 14:55:09 +01:00
parent 50b2d9af03
commit 002dae4390
1 changed files with 4 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/magicman-keyboard-luks.md
View File

@@ -50,8 +50,10 @@ driver sends a deactivate command (0xF5) during init, which likely succeeds at d
the keyboard even though the ACK times out. The subsequent enable command (0xF4) also the keyboard even though the ACK times out. The subsequent enable command (0xF4) also
times out without re-enabling it. The keyboard stays disabled at the hardware level — times out without re-enabling it. The keyboard stays disabled at the hardware level —
it queues keypresses in its small internal buffer (~16 keys) but doesn't send scancodes it queues keypresses in its small internal buffer (~16 keys) but doesn't send scancodes
to the host until something re-enables it during full boot (likely during switch-root to the host until something re-enables it during full boot. This is NOT a timing issue —
when udev re-processes devices). leaving the system at the LUKS prompt for several minutes does not fix the keyboard.
Something specific that happens later in the boot process (likely during switch-root
when udev re-processes devices) re-enables the keyboard.
## What Was Tried ## What Was Tried