Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
USB keyboard eject on lock screen bugs laptop keyboard
Reported by thebrahman · filed Feb 11, 2026 · open at source
At a glance
- 1 · What is claimed?
- RefutedReproducible: While the session lock is held, removing one keyboard leaves the remaining keyboard unable to type into the lock screen password field.
- 3 · Is it reproducible?
- An engine-executed run exited 0: the expected (correct) behaviour. See reproducer
- 4 · What remains unclear?
- Open question for maintainers: The report names a Lenovo Yoga 7 on Omarchy 3.3.3, whose lock was hyprlock. This run uses the current shell lock and two virtual keyboards on headless sway. Hyprland 0.56.2 is installed here but its backend did not start (CBackend::create failed), so a physical USB keyboard on Hyprland was not exercised.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. So far: in the audited area (lock) — decided by agents · verified; matches no known issue — decided by agents · verified. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.
Original report
System details
lenovo yoga 7 2025, omarchy 3.3.3
What's wrong?
unplugging USB keyboard while on lock screen bugs laptop keyboard. no keys are able to be pressed, unable to login, have to reboot.
View raw text
### System details lenovo yoga 7 2025, omarchy 3.3.3 ### What's wrong? unplugging USB keyboard while on lock screen bugs laptop keyboard. no keys are able to be pressed, unable to login, have to reboot.
Validation
AI validator grok-promoter-1 (grok-4.7) · evaluated revision 1 at product commit ecae57a237ef · sealed 2026-10-09T18:25:24Z
The report says that unplugging a USB keyboard while the lock screen is up makes the remaining laptop keyboard register no keys, so the password cannot be entered. At this baseline the lock is shell/plugins/lock (a WlSessionLock), not the hyprlock that Omarchy 3.3.3 used. No requirement states that a remaining keyboard keeps delivering keys after another keyboard is removed: SW-REQ-261004-VVN2 only drops auto-repeated presses, and SYS-REQ-260912-T0XP resets the layout when a lock is requested. The reproducer engages that lock on the project's headless sway session with two virtual keyboards, types one character, removes the other keyboard, and types again on the keyboard that stayed. The password field receives the second character. The lock known issues that were compared record wallpaper, fingerprint, PAM, blank-on-hotplug and sleep-lock budget failures, not a keyboard-removal trigger.
- RefutedReproducible
Reproducible: While the session lock is held, removing one keyboard leaves the remaining keyboard unable to type into the lock screen password field.
Engine: engine-executed run exited 0: the expected (correct) behaviour
Evidence: file pocs/reproducers/a withheld known issue/repro.sh
Validator's rationale (commentary): The report says unplugging a USB keyboard on the lock screen makes the remaining keyboard register no keys. The reproducer locks shell/plugins/lock, holds two virtual keyboards, types y, removes one keyboard, and types x on the keyboard that stayed. The second character arriving is the behaviour the report says does not happen.
- Fingerprint gate fail-open: substring grep treats not-enrolled or failed fprintd-list probes as enrolled KI-APPLY-LOCK-FPRINT-GATE-FAIL-OPEN
- Failed/empty readlink result stored as backgroundPath, wiping a good lock-screen wallpaper KI-LOCK-EMPTY-READLINK-WIPES-WALLPAPER
- Lock-service fingerprint probe fail-open: substring grep treats zero-enrollment fprintd-list output as configured KI-LOCK-FPRINT-PROBE-FAIL-OPEN
- omarchy-hyprland-session-locked has no deadline on hyprctl -j monitors; a stalled compositor IPC hangs the probe KI-LOCK-PROBE-HYPRCTL-NO-TIMEOUT
- Screen add/remove while locked clears the blank intent and never re-arms the idle blank timer KI-LOCK-SCREENS-CHANGE-BLANK-LOST
- Compositor-side lock loss with a request outstanding is treated as a finished unlock; no re-lock KI-LOCK-SPONTANEOUS-UNLOCK-FAIL-OPEN
- In-place video wallpaper overwrite during a running poster job keeps the stale poster frame KI-LOCK-STALE-POSTER-INPLACE-OVERWRITE
- Non-positive sleep-lock budget for logind windows <= 1s: suspend proceeds with no lock attempt KI-SLEEP-LOCK-BUDGET-NONPOSITIVE
- Header invariant 'every call bounded by the budget remainder' unenforced on three external calls KI-SLEEP-LOCK-DEADLINE-INVARIANT-GAPS
Engine reference checks at 85e0d95a3de1 (24/24 ok)
- okcommit85e0d95a3de109f570ece1425069a019006971c1
- okbase commitecae57a237ef4b084c234a25835b8145ddc5295d
- okbase ancestryecae57a237ef4b084c234a25835b8145ddc5295d
- okproduct code untouchedthis report's reproducer branch
- okbranchthis report's reproducer branch
- okfilepocs/reproducers/a withheld known issue/driver.qml
- okfilepocs/reproducers/a withheld known issue/repro.sh
- okcomponentlock
- okknown issuewithheld
- okknown issueKI-APPLY-LOCK-FPRINT-GATE-FAIL-OPEN
- okknown issuewithheld
- okknown issuewithheld
- okknown issueKI-LOCK-EMPTY-READLINK-WIPES-WALLPAPER
- okknown issueKI-LOCK-FPRINT-PROBE-FAIL-OPEN
- okknown issuewithheld
- okknown issuewithheld
- okknown issuewithheld
- okknown issueKI-LOCK-PROBE-HYPRCTL-NO-TIMEOUT
- okknown issueKI-LOCK-SCREENS-CHANGE-BLANK-LOST
- okknown issueKI-LOCK-SPONTANEOUS-UNLOCK-FAIL-OPEN
- okknown issueKI-LOCK-STALE-POSTER-INPLACE-OVERWRITE
- okknown issuewithheld
- okknown issueKI-SLEEP-LOCK-BUDGET-NONPOSITIVE
- okknown issueKI-SLEEP-LOCK-DEADLINE-INVARIANT-GAPS
The engine's own check, at validation time, that the commits, the reproducer branch (touching only reproducer files), the reproducer files and every mapped requirement / component / known issue really exist.
Validator-authored hypothesis. Each claim's verification is engine-computed: confirmed only from an engine-executed reproducer run recorded in this record, refuted when recorded evidence contradicts it. Prose is commentary. The disposition of the report is a human decision.
Reproducer
bash pocs/reproducers/a withheld known issue/repro.sh
Setup failure: exit 2 means the reproducer could not set up (e.g. the product did not build) — such a run decides nothing.
Defect signal: output contains PROOF-REPRODUCER: defect-present a withheld known issue
sway display=wayland-1 lock secure keyboards drop=3995866 hold=3995867 before removal password=pw="y" removed one keyboard; remaining keyboard still held by 3995867 after removal password=pw="yx" PROOF-REPRODUCER: defect-absent a withheld known issue
Needs: linux · headless sway, quickshell, wtype, and a user namespace (unshare -Urm) for a private PAM stack. PROOF_ENV_DIR supplies sway and wtype when they are not on PATH. · ran on linux/amd64 · The command stages the committed lock plugin into a temporary quickshell config. It does not build native code.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Decided by agents · verified: in the audited area (lock)
- Decided by agents · verified: matches no known issue
The outcome (valid, duplicate, not a bug, …) is not decided yet.