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-5310GitHub issuePublicDecided· Duplicate

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

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

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?
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 idleBlankTimer blanks display after only 5s on wake from suspend, racing dock/monitor hotplugsrevision 1 · captured 2026-10-10 17:56 UTC via poll

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

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

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-1584Decided by agents · verified · 2026-10-10 19:49 UTC