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.
Laptop with no external monitor has no path from lid-open to dpms enable: panel stays dark after resume
Reported by EitanSchuler · filed Sep 4, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #9628 (R-1101). 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
System details
Device: HP Spectre x360 2-in-1 Laptop 14-ef1xxx Omarchy: 4.0.2-1 Kernel: 7.1.9-arch1-2 GPU: Intel Iris Xe (ADL GT2), i915 Sleep: s2idle only Displays: internal eDP-1 only, no external monitor attached
What's wrong?
On a laptop with no external monitor, closing and reopening the lid leaves the internal panel dark. The machine has resumed correctly and is fully responsive, but nothing lights the screen. It looks exactly like a failed resume, and every occurrence here was ended with a forced power-off.
Pressing any key recovers it. The power button never does, which is what makes it look like a hang rather than a blank screen.
Why it happens, in shipped code
lock/Service.qml'sidleBlankTimerfires 5 seconds after locking and runsomarchy-brightness-display off, which dispatchesdpms disable. On lid close the sequence is: lock, five seconds later panel off, then suspend. The timer's own comment says fingerprint auth must not hold the panel up, so this happens on every lid-close lock.- Only two code paths ever dispatch
dpms enable:
omarchy-system-wake, reached solely fromKeys.onPressedon the lock screen's password field.dpms_internal enableinsideomarchy-hyprland-monitor-clamshell'senable_internal(), which sits behindif (( changed ))— true only when a clamshell flag file was just removed.
- That flag is never written when there is no external monitor. A laptop-only lid-open therefore runs the reconciler and dispatches nothing.
- The power button cannot rescue it: logind consumes it and
10-ignore-power-button.confignores it, so the compositor never sees a keypress.
Evidence
A clean 70-minute resume, journal showing no fault at all:
14:08:07 Lid opened
14:08:07 PM: suspend exit
14:08:07 backlight intel_backlight: PM: backlight_resume returned 0
14:08:07 tailscaled: monitor: time jump detected (slept 1h10m12s)
... lock screen loops fingerprint every 10s, six times, panel dark ...
14:08:49 systemd-logind: Power key pressed short
14:08:55 systemd-logind: Power key pressed short
14:09:03 systemd-logind: Power key pressed short
14:09:05 <log ends mid-line>Measured directly:
dpms before: [true]
after blank: [false] <- omarchy-brightness-display off, i.e. what the lock screen runs
after wake: [true] <- omarchy-system-wakeWhy this is easy to miss
It looks fine whenever the first thing you do after opening the lid is type. It looks like a dead machine whenever you reach for the power button. That intermittency is what kept it unexplained here for two days.
Local workaround
Replacing the default lid-open bind rather than adding a second one, so the reconciler still runs exactly once:
hl.unbind("switch:off:Lid Switch")
o.bind("switch:off:Lid Switch", "Lid open: reconcile displays, wake panel",
"bash -c 'omarchy-hyprland-monitor-clamshell; omarchy-system-wake'",
{ locked = true })Suggested fix
Either dispatch dpms enable unconditionally on lid-open rather than only when the clamshell flag changed, or move enable_internal()'s DPMS step outside the if (( changed )) guard.
View raw text
### System details
Device: HP Spectre x360 2-in-1 Laptop 14-ef1xxx Omarchy: 4.0.2-1 Kernel: 7.1.9-arch1-2 GPU: Intel Iris Xe (ADL GT2), i915 Sleep: s2idle only Displays: internal eDP-1 only, no external monitor attached
### What's wrong?
On a laptop with no external monitor, closing and reopening the lid leaves the internal panel dark. The machine has resumed correctly and is fully responsive, but nothing lights the screen. It looks exactly like a failed resume, and every occurrence here was ended with a forced power-off.
Pressing any key recovers it. The power button never does, which is what makes it look like a hang rather than a blank screen.
### Why it happens, in shipped code
1. `lock/Service.qml`'s `idleBlankTimer` fires **5 seconds** after locking and runs `omarchy-brightness-display off`, which dispatches `dpms disable`. On lid close the sequence is: lock, five seconds later panel off, then suspend. The timer's own comment says fingerprint auth must not hold the panel up, so this happens on every lid-close lock.
2. Only two code paths ever dispatch `dpms enable`:
- `omarchy-system-wake`, reached solely from `Keys.onPressed` on the lock screen's password field.
- `dpms_internal enable` inside `omarchy-hyprland-monitor-clamshell`'s `enable_internal()`, which sits behind `if (( changed ))` — true only when a clamshell flag file was just removed.
3. **That flag is never written when there is no external monitor.** A laptop-only lid-open therefore runs the reconciler and dispatches nothing.
4. The power button cannot rescue it: logind consumes it and `10-ignore-power-button.conf` ignores it, so the compositor never sees a keypress.
### Evidence
A clean 70-minute resume, journal showing no fault at all:
```
14:08:07 Lid opened
14:08:07 PM: suspend exit
14:08:07 backlight intel_backlight: PM: backlight_resume returned 0
14:08:07 tailscaled: monitor: time jump detected (slept 1h10m12s)
... lock screen loops fingerprint every 10s, six times, panel dark ...
14:08:49 systemd-logind: Power key pressed short
14:08:55 systemd-logind: Power key pressed short
14:09:03 systemd-logind: Power key pressed short
14:09:05 <log ends mid-line>
```
Measured directly:
```
dpms before: [true]
after blank: [false] <- omarchy-brightness-display off, i.e. what the lock screen runs
after wake: [true] <- omarchy-system-wake
```
### Why this is easy to miss
It looks fine whenever the first thing you do after opening the lid is type. It looks like a dead machine whenever you reach for the power button. That intermittency is what kept it unexplained here for two days.
### Local workaround
Replacing the default lid-open bind rather than adding a second one, so the reconciler still runs exactly once:
```lua
hl.unbind("switch:off:Lid Switch")
o.bind("switch:off:Lid Switch", "Lid open: reconcile displays, wake panel",
"bash -c 'omarchy-hyprland-monitor-clamshell; omarchy-system-wake'",
{ locked = true })
```
### Suggested fix
Either dispatch `dpms enable` unconditionally on lid-open rather than only when the clamshell flag changed, or move `enable_internal()`'s DPMS step outside the `if (( changed ))` guard.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
- Related PRpr/9211· 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.