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.
Lid-open binding does not restore display brightness after suspend
Reported by BjornB2 · filed Sep 1, 2026 · open at source
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-open binding does not explicitly restore display brightness after suspend
System details
- Omarchy:
4.0.2-1 - Hyprland:
0.56.2-1 - Quickshell:
0.3.1-1 - Kernel:
7.1.9-arch1-2 - Hardware: Apple MacBook10,1 (
Mac-EE2EBD4B90B839A8) - CPU: Intel Core i5-7Y54
- GPU: Intel HD Graphics 615 (
i915) - Sleep mode:
deep(S3)
What happens
After closing the lid for a longer period and reopening it, the machine resumes but the internal display can remain black for noticeably longer than normal. Pressing the power button makes the lock screen appear. Short suspend/resume cycles tend to show the display sooner.
The journal shows that the kernel resumes promptly and restores the ACPI backlight state in under one second, without i915 errors. For example:
16:53:19.330 systemd-logind: Lid opened.
16:53:20.076 kernel: acpi LNXVIDEO:00: Restoring backlight state
16:53:20.076 systemd-sleep: System returned from sleep operation 'suspend'.
16:53:20.077 kernel: PM: suspend exitRelevant default configuration
The default lid-open binding only reconciles clamshell state:
o.bind("switch:off:Lid Switch", nil, "omarchy-hyprland-monitor-clamshell", { locked = true })However, omarchy-system-wake explicitly restores both display and keyboard brightness and then performs that same clamshell reconciliation:
omarchy-brightness-display on
omarchy-brightness-keyboard restore
omarchy-hyprland-monitor-clamshell >/dev/null 2>&1 || trueExpected behavior
Opening the lid after suspend should immediately restore the display and keyboard backlight and show the lock screen.
Steps to reproduce
- Close the laptop lid and leave it suspended for several minutes or longer.
- Open the lid.
- Observe that the laptop resumes, but the display may remain black.
- Press the power button or provide another input event; the lock screen appears.
Local workaround under test
Override the default lid-open binding:
hl.unbind("switch:off:Lid Switch")
o.bind("switch:off:Lid Switch", nil, "omarchy-system-wake", { locked = true })Hyprland reloads this without configuration errors and the effective lid-open binding points to the replacement. A longer suspend is still needed to confirm that it resolves the intermittent delay.
Suggested fix
Use omarchy-system-wake for the default switch:off:Lid Switch binding. It is a superset of the existing command because it ends by invoking omarchy-hyprland-monitor-clamshell.
View raw text
# Lid-open binding does not explicitly restore display brightness after suspend
## System details
- Omarchy: `4.0.2-1`
- Hyprland: `0.56.2-1`
- Quickshell: `0.3.1-1`
- Kernel: `7.1.9-arch1-2`
- Hardware: Apple MacBook10,1 (`Mac-EE2EBD4B90B839A8`)
- CPU: Intel Core i5-7Y54
- GPU: Intel HD Graphics 615 (`i915`)
- Sleep mode: `deep` (S3)
## What happens
After closing the lid for a longer period and reopening it, the machine resumes but the internal display can remain black for noticeably longer than normal. Pressing the power button makes the lock screen appear. Short suspend/resume cycles tend to show the display sooner.
The journal shows that the kernel resumes promptly and restores the ACPI backlight state in under one second, without i915 errors. For example:
```text
16:53:19.330 systemd-logind: Lid opened.
16:53:20.076 kernel: acpi LNXVIDEO:00: Restoring backlight state
16:53:20.076 systemd-sleep: System returned from sleep operation 'suspend'.
16:53:20.077 kernel: PM: suspend exit
```
## Relevant default configuration
The default lid-open binding only reconciles clamshell state:
```lua
o.bind("switch:off:Lid Switch", nil, "omarchy-hyprland-monitor-clamshell", { locked = true })
```
However, `omarchy-system-wake` explicitly restores both display and keyboard brightness and then performs that same clamshell reconciliation:
```bash
omarchy-brightness-display on
omarchy-brightness-keyboard restore
omarchy-hyprland-monitor-clamshell >/dev/null 2>&1 || true
```
## Expected behavior
Opening the lid after suspend should immediately restore the display and keyboard backlight and show the lock screen.
## Steps to reproduce
1. Close the laptop lid and leave it suspended for several minutes or longer.
2. Open the lid.
3. Observe that the laptop resumes, but the display may remain black.
4. Press the power button or provide another input event; the lock screen appears.
## Local workaround under test
Override the default lid-open binding:
```lua
hl.unbind("switch:off:Lid Switch")
o.bind("switch:off:Lid Switch", nil, "omarchy-system-wake", { locked = true })
```
Hyprland reloads this without configuration errors and the effective lid-open binding points to the replacement. A longer suspend is still needed to confirm that it resolves the intermittent delay.
## Suggested fix
Use `omarchy-system-wake` for the default `switch:off:Lid Switch` binding. It is a superset of the existing command because it ends by invoking `omarchy-hyprland-monitor-clamshell`.
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.
- Out of scopeDecided by agents · verified · 2026-10-09 10:28 UTC