Proof Portal

Sign in
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-448GitHub issuePublicDecided· Out of scope

Lid close starts suspend immediately; a quick reopen leaves a dark screen

Reported by ijt · filed Sep 16, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 days ago.

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?
AreaOutside the audited area· 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

Lid close starts suspend immediately; a quick reopen leaves a dark screenrevision 1 · captured 2026-09-28 21:23 UTC via poll

System details

  • Omarchy 4.0.2-1
  • Kernel 7.1.9-arch1-2
  • Hardware: Apple MacBookPro14,2 (also reproduced the race on this machine; the race itself is not Mac-specific)
  • Hyprland + omarchy-system-lid-close on switch:on:Lid Switch
  • logind still at the compiled default HandleLidSwitch=suspend

What happened

Closing the lid starts S3 immediately. Opening it a couple of seconds later does not bring the session back: the screen stays dark until a forced power-off, or until a long wait if S3 eventually finishes.

Journal of a typical miss (lid opened after logind had already committed to suspend, before the kernel finished entering S3):

systemd-logind: Lid closed.
systemd-logind: Suspending...
systemd-logind: Lid opened.          # same second as freeze
systemd-sleep: Successfully froze unit 'user.slice'.
kernel: PM: suspend entry (deep)
# no matching PM: suspend exit until reboot, or a long delayed resume

Hyprland never sees switch:off:Lid Switch because user.slice is frozen. The panel stays at the lid-closed DPMS/backlight state.

Related: #7788 describes the same close/open-while-suspending race on different hardware.

Expected

  • A short close/open (a few seconds) should lock, then come straight back.
  • A lid that stays shut should still suspend so the machine does not cook in a bag.
  • Opening the lid during/after suspend should turn the internal panel back on.

Steps to reproduce

  1. Undocked laptop, no external displays.
  2. Close the lid for ~2s and open it. Session may already be committed to suspend.
  3. Close the lid for ~6s and open it. Screen stays dark well after the kernel has resumed.

What worked here

Do not let logind and Hyprland both drive lid-close suspend.

  1. HandleLidSwitch=ignore (and the ExternalPower / Docked variants) in a logind drop-in, so only Hyprland owns the lid.
  2. Keep omarchy-system-lid-close on lid close (lock immediately, clamshell). That part is correct.
  3. Only call systemctl suspend from a debounced helper: sleep a couple of seconds, then suspend if omarchy-hw-laptop-closed is still true and there are no external monitors. Cancel the pending job on lid open.
  4. On lid open, and ~1s after thaw (systemd-sleep post, once user.slice is unfrozen), force the panel on: omarchy-system-wake plus an explicit Hyprland DPMS enable. omarchy-brightness-display on can no-op when dpmsStatus is already true, which is wrong after S3 if backlight was saved at 0.

A 2–3s debounce is enough to kill the race on any laptop. A much longer delay (we used 20s locally) was only because S3 resume on this particular Alpine Ridge machine is ~7s; that number should not be the Omarchy default.

Suggested shape

  • logind drop-in: HandleLidSwitch=ignore
  • omarchy-system-lid-close stays the lock/clamshell path
  • small helper: debounce then systemctl suspend, killed on lid open
  • lid-open bind + post-thaw hook: wake displays if the lid is open
  • do not change HandleLidSwitchDocked; clamshell should stay awake
View raw text
## System details

- Omarchy `4.0.2-1`
- Kernel `7.1.9-arch1-2`
- Hardware: Apple `MacBookPro14,2` (also reproduced the *race* on this machine; the race itself is not Mac-specific)
- Hyprland + `omarchy-system-lid-close` on `switch:on:Lid Switch`
- logind still at the compiled default `HandleLidSwitch=suspend`

## What happened

Closing the lid starts S3 immediately. Opening it a couple of seconds later does not bring the session back: the screen stays dark until a forced power-off, or until a long wait if S3 eventually finishes.

Journal of a typical miss (lid opened *after* logind had already committed to suspend, *before* the kernel finished entering S3):

```
systemd-logind: Lid closed.
systemd-logind: Suspending...
systemd-logind: Lid opened.          # same second as freeze
systemd-sleep: Successfully froze unit 'user.slice'.
kernel: PM: suspend entry (deep)
# no matching PM: suspend exit until reboot, or a long delayed resume
```

Hyprland never sees `switch:off:Lid Switch` because `user.slice` is frozen. The panel stays at the lid-closed DPMS/backlight state.

Related: #7788 describes the same close/open-while-suspending race on different hardware.

## Expected

- A short close/open (a few seconds) should lock, then come straight back.
- A lid that stays shut should still suspend so the machine does not cook in a bag.
- Opening the lid during/after suspend should turn the internal panel back on.

## Steps to reproduce

1. Undocked laptop, no external displays.
2. Close the lid for ~2s and open it. Session may already be committed to suspend.
3. Close the lid for ~6s and open it. Screen stays dark well after the kernel has resumed.

## What worked here

Do **not** let logind and Hyprland both drive lid-close suspend.

1. `HandleLidSwitch=ignore` (and the ExternalPower / Docked variants) in a logind drop-in, so only Hyprland owns the lid.
2. Keep `omarchy-system-lid-close` on lid close (lock immediately, clamshell). That part is correct.
3. Only call `systemctl suspend` from a **debounced** helper: sleep a couple of seconds, then suspend if `omarchy-hw-laptop-closed` is still true and there are no external monitors. Cancel the pending job on lid open.
4. On lid open, and ~1s after thaw (systemd-sleep `post`, once `user.slice` is unfrozen), force the panel on: `omarchy-system-wake` plus an explicit Hyprland DPMS enable. `omarchy-brightness-display on` can no-op when `dpmsStatus` is already true, which is wrong after S3 if backlight was saved at 0.

A 2–3s debounce is enough to kill the race on any laptop. A much longer delay (we used 20s locally) was only because S3 resume on this particular Alpine Ridge machine is ~7s; that number should not be the Omarchy default.

## Suggested shape

- logind drop-in: `HandleLidSwitch=ignore`
- `omarchy-system-lid-close` stays the lock/clamshell path
- small helper: debounce then `systemctl suspend`, killed on lid open
- lid-open bind + post-thaw hook: wake displays if the lid is open
- do not change `HandleLidSwitchDocked`; clamshell should stay awake

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

Not linked to any known issue, other report or change yet.

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.

  • Out of scopeDecided by agents · verified · 2026-10-09 14:35 UTC