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 re-blanks ~1s after DPMS wake on slow-sync monitor, making unlock blind typing
Reported by skinandbones · filed Aug 18, 2026 · open at source
This defect is tracked under R-1584. This report describes the same defect, so it is folded under it in the inbox.
Earliest report of this defect: R-1678 (filed Aug 18, 2026).
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?
- 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
System details
AMD Ryzen AI MAX+ 395 (Radeon 8060S / Strix Halo, RADV), ASUS ProArt PA32QCV (6K) on DP-4, Omarchy 4.0.0-1, single monitor, no fingerprint.
What's wrong?
After the idle lock blanks the display, waking it is nearly unusable on this monitor:
- Screen locks (idle or manual), display blanks ~5s later — expected, per
plugins/lock/Service.qmlidleBlankTimer(hardcodedinterval: 5000). - Pressing a key wakes the display, but the password prompt is visible for only ~1 second before the display goes dark again.
- Repeating input repeats the 1-second flash. The input path itself works fine: typing the password blind and pressing Enter unlocks normally.
This panel takes ~4s to resync a 6K DP signal after DPMS off, so whatever re-blanks it leaves effectively no usable window.
What I ruled out
I cloned omarchy.lock and raised idleBlankTimer.interval from 5000 to 30000. The symptom did not change — the display still went dark ~1s after each wake. So the re-blank does not appear to come from the lock plugin's blank timer at all (every keystroke re-arms it via wakeRequested anyway).
Remaining suspects on the wake path:
omarchy-brightness-display onskips the DPMS enable dispatch whenhyprctl monitors -jreports all displaysdpmsStatus: true. If that status flips true before the panel has actually resynced (e.g. Hyprland enabling DPMS itself on key press), the guard may be masking a failed/incomplete enable.- 6K-over-DP link retraining after DPMS wake: the panel briefly shows a picture, then loses link and drops back to sleep — consistent with a modeset race rather than a deliberate blank.
Timeline from journal (idle lock at 11:45, wake+unlock at 11:50)
15:45:36.704Z idle lock-system: lock-timeout
15:45:36.780Z lock lock-requested
15:45:37.303Z lock secure=true
15:50:36.052Z idle idle-cycle-cancel: activity <- first key press, omarchy-system-wake runs
15:50:45.060Z lock unlocked <- 9s of blind typing laterSteps to reproduce
- Omarchy 4 with a monitor that is slow to resync after DPMS off (large 6K/DSC panels).
- Lock and wait for the display to blank.
- Press a key: prompt appears for ~1s, display goes dark again.
- Type the password blind: unlock succeeds, confirming only the display path is broken.
Suggestions
- Make the lock blank delay configurable (the 5000ms in
plugins/lock/Service.qmlis hardcoded), though per the above that alone does not fix this. - Re-examine the
dpmsStatusskip-guard inomarchy-brightness-display onfor staleness during wake, and consider not blanking at all while the password buffer is non-empty.
View raw text
## System details AMD Ryzen AI MAX+ 395 (Radeon 8060S / Strix Halo, RADV), ASUS ProArt PA32QCV (6K) on DP-4, Omarchy 4.0.0-1, single monitor, no fingerprint. ## What's wrong? After the idle lock blanks the display, waking it is nearly unusable on this monitor: 1. Screen locks (idle or manual), display blanks ~5s later — expected, per `plugins/lock/Service.qml` `idleBlankTimer` (hardcoded `interval: 5000`). 2. Pressing a key wakes the display, but the password prompt is visible for only **~1 second** before the display goes dark again. 3. Repeating input repeats the 1-second flash. The input path itself works fine: typing the password blind and pressing Enter unlocks normally. This panel takes ~4s to resync a 6K DP signal after DPMS off, so whatever re-blanks it leaves effectively no usable window. ## What I ruled out I cloned `omarchy.lock` and raised `idleBlankTimer.interval` from 5000 to 30000. **The symptom did not change** — the display still went dark ~1s after each wake. So the re-blank does not appear to come from the lock plugin's blank timer at all (every keystroke re-arms it via `wakeRequested` anyway). Remaining suspects on the wake path: - `omarchy-brightness-display on` skips the DPMS enable dispatch when `hyprctl monitors -j` reports all displays `dpmsStatus: true`. If that status flips true before the panel has actually resynced (e.g. Hyprland enabling DPMS itself on key press), the guard may be masking a failed/incomplete enable. - 6K-over-DP link retraining after DPMS wake: the panel briefly shows a picture, then loses link and drops back to sleep — consistent with a modeset race rather than a deliberate blank. ## Timeline from journal (idle lock at 11:45, wake+unlock at 11:50) ``` 15:45:36.704Z idle lock-system: lock-timeout 15:45:36.780Z lock lock-requested 15:45:37.303Z lock secure=true 15:50:36.052Z idle idle-cycle-cancel: activity <- first key press, omarchy-system-wake runs 15:50:45.060Z lock unlocked <- 9s of blind typing later ``` ## Steps to reproduce 1. Omarchy 4 with a monitor that is slow to resync after DPMS off (large 6K/DSC panels). 2. Lock and wait for the display to blank. 3. Press a key: prompt appears for ~1s, display goes dark again. 4. Type the password blind: unlock succeeds, confirming only the display path is broken. ## Suggestions - Make the lock blank delay configurable (the 5000ms in `plugins/lock/Service.qml` is hardcoded), though per the above that alone does not fix this. - Re-examine the `dpmsStatus` skip-guard in `omarchy-brightness-display on` for staleness during wake, and consider not blanking at all while the password buffer is non-empty.
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/8773· confirmed
- Related PRpr/8561· confirmed
- Duplicate ofR-1584[Quattro] Lock screen re-blanks slow DPMS monitors after fixed 5-second wake timeout· decided by agents · verified
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.