Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-2185GitHub issuePublicFixed

Lock screen ignores keyboard after lid close/resume until clicked

Reported by nateyoungrig · filed Oct 2, 2026 · open at source

Open at source
Decided: Duplicate — decided by agents · verified 3 days ago.
Duplicate of[Quattro] Lock password field can lose focus after suspend resume R-1214

R-1214 is the earliest report of this defect — filed Aug 30, 2026, open upstream. This report (filed Oct 2, 2026) describes the same defect, so it is folded under it in the inbox.

Decided by agents · verified· Oct 9, 2026

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
AreaIn the audited arealock· Decided by agents · verified
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

Lock screen ignores keyboard after lid close/resume until clickedrevision 1 · captured 2026-10-02 17:18 UTC via poll

Description

After closing the lid while the lock screen is up, the lock screen ignores the built-in keyboard on resume. Keystrokes don't register in the password field until the lock screen is clicked.

Steps to reproduce

  1. omarchy system lock
  2. Close the lid (s2idle suspend) and wait ~10s
  3. Open the lid and type the password without touching the mouse/touchpad

Expected: keystrokes go to the password field.
Actual: nothing registers until the lock screen is clicked.

What I ruled out

  • Locking without suspending works; typing registers immediately.
  • Locking, waiting for the 5s DPMS blank, then typing works.
  • Launching the screensaver, then locking (so omarchy-system-lock kills the screensaver window under the lock) works.
  • Single keyboard layout; the built-in keyboard (at-translated-set-2-keyboard), not Bluetooth.

Likely cause

On resume, the Hyprland log shows every libinput device removed and re-added (including the built-in keyboard) as the seat is disabled and re-enabled.

In shell/plugins/lock/LockView.qml, forcePasswordFocus() is only called from Component.onCompleted, onInputEnabledChanged, and the full-screen MouseArea's onClicked. Nothing refocuses the password field after resume, which matches clicking being the only thing that recovers it.

System

  • ThinkPad P1 Gen 3 (Intel i9-10885H + NVIDIA hybrid graphics)
  • Omarchy 4.0.4-1
  • Hyprland 0.56.2
  • Kernel 7.2.5-3-omarchy
  • Single internal display (eDP-1), scale 2

Diagnostics

omarchy debug log (MAC addresses, IPs, and UUIDs redacted; expires in 24h): https://logs.omarchy.org/q46iFi

View raw text
### Description

After closing the lid while the lock screen is up, the lock screen ignores the built-in keyboard on resume. Keystrokes don't register in the password field until the lock screen is clicked.

### Steps to reproduce

1. `omarchy system lock`
2. Close the lid (s2idle suspend) and wait ~10s
3. Open the lid and type the password without touching the mouse/touchpad

**Expected:** keystrokes go to the password field.
**Actual:** nothing registers until the lock screen is clicked.

### What I ruled out

- Locking without suspending works; typing registers immediately.
- Locking, waiting for the 5s DPMS blank, then typing works.
- Launching the screensaver, then locking (so `omarchy-system-lock` kills the screensaver window under the lock) works.
- Single keyboard layout; the built-in keyboard (`at-translated-set-2-keyboard`), not Bluetooth.

### Likely cause

On resume, the Hyprland log shows every libinput device removed and re-added (including the built-in keyboard) as the seat is disabled and re-enabled.

In `shell/plugins/lock/LockView.qml`, `forcePasswordFocus()` is only called from `Component.onCompleted`, `onInputEnabledChanged`, and the full-screen `MouseArea`'s `onClicked`. Nothing refocuses the password field after resume, which matches clicking being the only thing that recovers it.

### System

- ThinkPad P1 Gen 3 (Intel i9-10885H + NVIDIA hybrid graphics)
- Omarchy 4.0.4-1
- Hyprland 0.56.2
- Kernel 7.2.5-3-omarchy
- Single internal display (eDP-1), scale 2

### Diagnostics

`omarchy debug` log (MAC addresses, IPs, and UUIDs redacted; expires in 24h): https://logs.omarchy.org/q46iFi

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

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.

  • DuplicateR-1214Decided by agents · verified · 2026-10-09 09:23 UTC