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
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
to the host until something re-enables it during full boot (likely during switch-root
when udev re-processes devices).
to the host until something re-enables it during full boot. This is NOT a timing issue —
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