Proof Portal

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-300GitHub issuePublicFixed

Lock screen password field loses keyboard focus after DPMS wake

Reported by lunacava · filed Sep 20, 2026 · open at source

Decided: Duplicate — decided by agents · verified 3 days ago.

R-1214 is the earliest report of this defect — filed Aug 30, 2026, open upstream. This report (filed Sep 20, 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 password field loses keyboard focus after DPMS wakerevision 1 · captured 2026-09-28 21:23 UTC via poll

What happened

After the display wakes from DPMS-off (screen blanked) while the Omarchy session lock (Quickshell WlSessionLock / LockView.qml) is active, the password field is not keyboard-focused. Typing does nothing until the mouse is clicked once — only then does the field accept keyboard input.

What was expected

The password field should already have keyboard focus when the display wakes, so the password can be typed immediately (as it does immediately after first locking, before the display blanks).

Steps to reproduce

  1. Let the system idle past idle.lock (default screen lock timeout) so the session lock engages and the display blanks (DPMS off).
  2. Wake the display (move the mouse or press a key — misc:key_press_enables_dpms is already true on this system, so a keypress does wake the display).
  3. Try typing the password immediately: no characters appear in the field.
  4. Click anywhere with the mouse: the field now accepts keyboard input normally.

Suspected root cause

LockView.qml already calls passwordInput.forceActiveFocus() in Component.onCompleted and whenever inputEnabled changes, so the QML side looks correct. The mismatch seems to be at the Hyprland compositor level: input:mouse_refocus defaults to true (alongside input:follow_mouse = 1), which re-evaluates window/surface focus based on pointer state. This appears to interact badly with the exclusive keyboard focus that the ext-session-lock-v1 surface (WlSessionLockSurface) should hold across a DPMS off/on cycle — the surface loses real (compositor-level) keyboard focus even though Qt's internal activeFocus state on the TextInput is untouched.

Workaround

Setting the following in ~/.config/hypr/input.lua fixes it:

hl.config({
  input = {
    mouse_refocus = false,
  },
})

After this change, waking from a DPMS-off lock screen accepts keyboard input immediately, no click required.

System details

  • Omarchy: 4.0.3-1
  • Hyprland: 0.56.2 (commit efb50993780079460b0cbed1363e2166a2de1d9f)
  • Quickshell: 0.3.1-1
  • CPU: Intel Core i7-8565U
  • GPU: Intel UHD Graphics 620 (iGPU) + NVIDIA GeForce MX150 (hybrid graphics, nvidia driver in use)
  • Single monitor (eDP-1, internal laptop display)
  • Relevant config: idle.lock = 300 in ~/.config/omarchy/shell.json; input:key_press_enables_dpms = true, input:mouse_refocus = true (default, before workaround), input:follow_mouse = 1 (default)

Notes

  • omarchy debug was not available on this installed version (4.0.3-1) — omarchy commands --all has no debug entry — so no automated diagnostic log/URL is attached. Happy to run it and update the issue if it's the wrong command name for this version.
View raw text
## What happened

After the display wakes from DPMS-off (screen blanked) while the Omarchy session lock (Quickshell `WlSessionLock` / `LockView.qml`) is active, the password field is **not keyboard-focused**. Typing does nothing until the mouse is clicked once — only then does the field accept keyboard input.

## What was expected

The password field should already have keyboard focus when the display wakes, so the password can be typed immediately (as it does immediately after first locking, before the display blanks).

## Steps to reproduce

1. Let the system idle past `idle.lock` (default screen lock timeout) so the session lock engages and the display blanks (DPMS off).
2. Wake the display (move the mouse or press a key — `misc:key_press_enables_dpms` is already `true` on this system, so a keypress does wake the display).
3. Try typing the password immediately: no characters appear in the field.
4. Click anywhere with the mouse: the field now accepts keyboard input normally.

## Suspected root cause

`LockView.qml` already calls `passwordInput.forceActiveFocus()` in `Component.onCompleted` and whenever `inputEnabled` changes, so the QML side looks correct. The mismatch seems to be at the Hyprland compositor level: `input:mouse_refocus` defaults to `true` (alongside `input:follow_mouse = 1`), which re-evaluates window/surface focus based on pointer state. This appears to interact badly with the exclusive keyboard focus that the `ext-session-lock-v1` surface (`WlSessionLockSurface`) should hold across a DPMS off/on cycle — the surface loses real (compositor-level) keyboard focus even though Qt's internal `activeFocus` state on the `TextInput` is untouched.

## Workaround

Setting the following in `~/.config/hypr/input.lua` fixes it:

```lua
hl.config({
  input = {
    mouse_refocus = false,
  },
})
```

After this change, waking from a DPMS-off lock screen accepts keyboard input immediately, no click required.

## System details

- Omarchy: 4.0.3-1
- Hyprland: 0.56.2 (commit efb50993780079460b0cbed1363e2166a2de1d9f)
- Quickshell: 0.3.1-1
- CPU: Intel Core i7-8565U
- GPU: Intel UHD Graphics 620 (iGPU) + NVIDIA GeForce MX150 (hybrid graphics, `nvidia` driver in use)
- Single monitor (eDP-1, internal laptop display)
- Relevant config: `idle.lock = 300` in `~/.config/omarchy/shell.json`; `input:key_press_enables_dpms = true`, `input:mouse_refocus = true` (default, before workaround), `input:follow_mouse = 1` (default)

## Notes

- `omarchy debug` was not available on this installed version (4.0.3-1) — `omarchy commands --all` has no `debug` entry — so no automated diagnostic log/URL is attached. Happy to run it and update the issue if it's the wrong command name for this version.

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:24 UTC