From 002dae43903575e7e2569cfc3c2d14a3e62c91f9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Torjus=20H=C3=A5kestad?= Date: Fri, 6 Mar 2026 14:55:09 +0100 Subject: [PATCH] docs: clarify keyboard issue is not timing-related Co-Authored-By: Claude Opus 4.6 --- docs/magicman-keyboard-luks.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/magicman-keyboard-luks.md b/docs/magicman-keyboard-luks.md index 3600feb..03b8ca6 100644 --- a/docs/magicman-keyboard-luks.md +++ b/docs/magicman-keyboard-luks.md @@ -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