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.
Lock screen password field loses keyboard focus after DPMS blank (hybrid NVIDIA GPU)
Reported by SamW7890 · filed Sep 1, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #6858 (R-1866). GitHub close reason: completed.
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?
- Not yet mapped to any requirement or component.
- 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?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
What happened
After the lock screen has been up for a while (long enough for the display to
blank), keystrokes stop reaching the password field. Neither typing nor
pressing keys wakes the screen or enters text. Only clicking directly on the
password field restores both the display and the ability to type — moving
the mouse without clicking wakes the display but typing still does nothing
until the field is explicitly clicked.
What was expected
Since the lock screen already auto-focuses the password field on show
(LockView.qml's forcePasswordFocus(), called from Component.onCompleted
and onInputEnabledChanged), keyboard input should wake the display and be
typed into the field without needing a mouse click, the same way it works
immediately after locking (before the idle blank kicks in).
Steps to reproduce
- Lock the session (
omarchy system lock, or letidle.lockin
shell.json trigger it).
2. Wait past the lock screen's own idle-blank timeout (idleBlankTimer in
Service.qml, 5s by default) without touching anything, so the display
goes to DPMS off.
3. Try to type the password directly (no mouse click first).
4. Observe: nothing is typed and the screen does not wake.
5. Click on the password field: the screen wakes and typing now works.
Suspected cause (from reading the shipped QML)
In /usr/share/omarchy/shell/plugins/lock/LockView.qml:
- forcePasswordFocus() is invoked from Component.onCompleted and
onInputEnabledChanged, and explicitly from the background MouseArea's
onClicked handler (line ~118).
- The background MouseArea's onPositionChanged (mouse move without a
click) and passwordInput's Keys.onPressed both call
root.wakeRequested() (which runs omarchy-system-wake, restoring DPMS),
but neither path calls forcePasswordFocus().
If the password field's activeFocus is lost at some point during/after the
DPMS-off cycle (e.g. via a Quickshell.onScreensChanged -> requestSessionLock()
remap in Service.qml, which does not re-run Component.onCompleted), then:
- A keypress can't fire passwordInput's Keys.onPressed at all (no focus),
so it can't even trigger the wake.
- A mouse move wakes the display via onPositionChanged, but doesn't restore
focus, so typing still does nothing until an explicit click.
This would explain why the issue only appears once the screen has actually
gone idle-blank, not right when the lock screen first appears.
System details
- Omarchy: 4.0.1-1
- Hyprland: 0.56.2 (v0.56.2)
- Kernel: 7.1.9-arch1-2
- GPU: hybrid — NVIDIA GeForce RTX 3060 Mobile/Max-Q (
nvidiadriver) + AMD
Radeon Vega (Cezanne, amdgpu driver), Lenovo laptop
- idle.lock: 300s, idle.screensaver: 150s (defaults, from shell.json)
Note
omarchy debug --no-sudo --print (as documented) does not exist as a command
on this version — omarchy commands --all has no debug entry.
View raw text
### What happened After the lock screen has been up for a while (long enough for the display to blank), keystrokes stop reaching the password field. Neither typing nor pressing keys wakes the screen or enters text. Only clicking directly on the password field restores both the display and the ability to type — moving the mouse without clicking wakes the display but typing still does nothing until the field is explicitly clicked. ### What was expected Since the lock screen already auto-focuses the password field on show (`LockView.qml`'s `forcePasswordFocus()`, called from `Component.onCompleted` and `onInputEnabledChanged`), keyboard input should wake the display and be typed into the field without needing a mouse click, the same way it works immediately after locking (before the idle blank kicks in). ### Steps to reproduce 1. Lock the session (`omarchy system lock`, or let `idle.lock` in `shell.json` trigger it). 2. Wait past the lock screen's own idle-blank timeout (`idleBlankTimer` in `Service.qml`, 5s by default) without touching anything, so the display goes to DPMS off. 3. Try to type the password directly (no mouse click first). 4. Observe: nothing is typed and the screen does not wake. 5. Click on the password field: the screen wakes and typing now works. ### Suspected cause (from reading the shipped QML) In `/usr/share/omarchy/shell/plugins/lock/LockView.qml`: - `forcePasswordFocus()` is invoked from `Component.onCompleted` and `onInputEnabledChanged`, and explicitly from the background `MouseArea`'s `onClicked` handler (line ~118). - The background `MouseArea`'s `onPositionChanged` (mouse move without a click) and `passwordInput`'s `Keys.onPressed` both call `root.wakeRequested()` (which runs `omarchy-system-wake`, restoring DPMS), but neither path calls `forcePasswordFocus()`. If the password field's `activeFocus` is lost at some point during/after the DPMS-off cycle (e.g. via a `Quickshell.onScreensChanged` -> `requestSessionLock()` remap in `Service.qml`, which does not re-run `Component.onCompleted`), then: - A keypress can't fire `passwordInput`'s `Keys.onPressed` at all (no focus), so it can't even trigger the wake. - A mouse move wakes the display via `onPositionChanged`, but doesn't restore focus, so typing still does nothing until an explicit click. This would explain why the issue only appears once the screen has actually gone idle-blank, not right when the lock screen first appears. ### System details - Omarchy: 4.0.1-1 - Hyprland: 0.56.2 (v0.56.2) - Kernel: 7.1.9-arch1-2 - GPU: hybrid — NVIDIA GeForce RTX 3060 Mobile/Max-Q (`nvidia` driver) + AMD Radeon Vega (Cezanne, `amdgpu` driver), Lenovo laptop - `idle.lock`: 300s, `idle.screensaver`: 150s (defaults, from `shell.json`) ### Note `omarchy debug --no-sudo --print` (as documented) does not exist as a command on this version — `omarchy commands --all` has no `debug` entry.
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
- Fixed bypr/13907· confirmed
- Related PRpr/8560· confirmed
- Fixed bypr/7471· confirmed
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.
No decision has been recorded yet.