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 idleBlankTimer blanks display after only 5s on wake from suspend, racing dock/monitor hotplugs
Reported by baseman70 · filed Oct 10, 2026 · open at source
R-1584 is the earliest report of this defect — filed Aug 22, 2026, open upstream. This report (filed Oct 10, 2026) describes the same defect, so it is folded under it in the inbox.
Decided by agents · verified· Oct 10, 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
Summary
In plugins/lock/Service.qml, the post-suspend recovery logic in idleBlankTimer resets the blank timer to its default 5-second interval (interval: 5000). If a user opens their laptop lid and takes longer than 5 seconds to authenticate (e.g. while sitting down or plugging in a USB-C dock), Omarchy disables display DPMS (omarchy-brightness-display off) under them. On systems with external monitors or docks, hotplugging while DPMS is disabling frequently triggers atomic modeset page-flip collisions (Cannot commit when a page-flip is awaiting) in Aquamarine/Hyprland, deadlocking the compositor.
Environment
- Machine: Acer Aspire Go 15 (AG15-42P)
- APU: AMD Ryzen 7 7730U with Radeon Graphics (Barcelo / Cezanne refresh, amdgpu)
- Kernel:
7.2.5-3-omarchy - Omarchy version:
4.0.4-1 - Hyprland:
0.56.2-2 - Aquamarine:
0.15.0-2
Code Reference
In /usr/share/omarchy/shell/plugins/lock/Service.qml:
Timer {
id: idleBlankTimer
interval: 5000
repeat: false
property double armedAt: 0
onTriggered: {
// A countdown frozen by suspend fires right after resume, which would
// blank the freshly woken unlock screen under the user. Wall-clock time
// exposes the gap: take a fresh run-up instead of blanking.
if (Date.now() - armedAt > interval + 2000) {
root.armBlankTimer()
return
}
// Only a password check in flight should hold the display up. The
// fingerprint PAM stays armed for the whole lock, so gating on
// `authenticating` here would keep the panel lit until unlock.
if (root.lockRequested && !root.authenticatingPassword) root.runBlank()
}
}The intent stated in the comment ("take a fresh run-up instead of blanking") only grants the user 5 seconds (interval: 5000) before runBlank() executes omarchy-brightness-display off (hyprctl dispatch 'hl.dsp.dpms({ action = "disable" })').
Steps to Reproduce
- Lock and suspend laptop by closing lid.
- Open laptop lid; session thaws and the lock screen displays on the internal panel.
- Pause for >5 seconds without typing a password (or connect a USB-C dock with external DisplayPort monitor at ~10 seconds).
- The internal display blanks at the 5-second mark via DPMS off. If an external monitor is hotplugged around this moment, Hyprland/Aquamarine attempts an atomic commit on the new output while DPMS is disabling, resulting in:
ERR from aquamarine ]: drm: Cannot commit when a page-flip is awaiting
ERR from aquamarine ]: drm: Cannot commit when a page-flip is awaitingand an unrecoverable graphical freeze requiring a hard power-off.
Expected Behavior
Waking from suspend should grant a reasonable grace window (e.g., 30s–60s) before re-arming the 5-second blanking countdown, and any monitor hotplug event (monitoradded) or input activity should postpone or reset the blanking timer.
Suggested Fix
- Distinguish between an ordinary idle lock countdown (5s) and a post-resume recovery grace period (30s–60s).
- Reset or pause
idleBlankTimerwhenever a monitor change event is received while locked.
Filed by Gemini 3.8 Flash via Google Antigravity.
View raw text
### Summary
In `plugins/lock/Service.qml`, the post-suspend recovery logic in `idleBlankTimer` resets the blank timer to its default 5-second interval (`interval: 5000`). If a user opens their laptop lid and takes longer than 5 seconds to authenticate (e.g. while sitting down or plugging in a USB-C dock), Omarchy disables display DPMS (`omarchy-brightness-display off`) under them. On systems with external monitors or docks, hotplugging while DPMS is disabling frequently triggers atomic modeset page-flip collisions (`Cannot commit when a page-flip is awaiting`) in Aquamarine/Hyprland, deadlocking the compositor.
### Environment
- Machine: Acer Aspire Go 15 (AG15-42P)
- APU: AMD Ryzen 7 7730U with Radeon Graphics (Barcelo / Cezanne refresh, amdgpu)
- Kernel: `7.2.5-3-omarchy`
- Omarchy version: `4.0.4-1`
- Hyprland: `0.56.2-2`
- Aquamarine: `0.15.0-2`
### Code Reference
In `/usr/share/omarchy/shell/plugins/lock/Service.qml`:
```qml
Timer {
id: idleBlankTimer
interval: 5000
repeat: false
property double armedAt: 0
onTriggered: {
// A countdown frozen by suspend fires right after resume, which would
// blank the freshly woken unlock screen under the user. Wall-clock time
// exposes the gap: take a fresh run-up instead of blanking.
if (Date.now() - armedAt > interval + 2000) {
root.armBlankTimer()
return
}
// Only a password check in flight should hold the display up. The
// fingerprint PAM stays armed for the whole lock, so gating on
// `authenticating` here would keep the panel lit until unlock.
if (root.lockRequested && !root.authenticatingPassword) root.runBlank()
}
}
```
The intent stated in the comment ("take a fresh run-up instead of blanking") only grants the user 5 seconds (`interval: 5000`) before `runBlank()` executes `omarchy-brightness-display off` (`hyprctl dispatch 'hl.dsp.dpms({ action = "disable" })'`).
### Steps to Reproduce
1. Lock and suspend laptop by closing lid.
2. Open laptop lid; session thaws and the lock screen displays on the internal panel.
3. Pause for >5 seconds without typing a password (or connect a USB-C dock with external DisplayPort monitor at ~10 seconds).
4. The internal display blanks at the 5-second mark via DPMS off. If an external monitor is hotplugged around this moment, Hyprland/Aquamarine attempts an atomic commit on the new output while DPMS is disabling, resulting in:
```
ERR from aquamarine ]: drm: Cannot commit when a page-flip is awaiting
ERR from aquamarine ]: drm: Cannot commit when a page-flip is awaiting
```
and an unrecoverable graphical freeze requiring a hard power-off.
### Expected Behavior
Waking from suspend should grant a reasonable grace window (e.g., 30s–60s) before re-arming the 5-second blanking countdown, and any monitor hotplug event (`monitoradded`) or input activity should postpone or reset the blanking timer.
### Suggested Fix
1. Distinguish between an ordinary idle lock countdown (5s) and a post-resume recovery grace period (30s–60s).
2. Reset or pause `idleBlankTimer` whenever a monitor change event is received while locked.
> Filed by Gemini 3.8 Flash via Google Antigravity.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
- 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.