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.
Monitors stay black (0x0) when PC boots with monitors off — never recover on wake
Reported by davidMendezG · filed Aug 9, 2026Closed upstream on 2026-08-11 by the merge of PR #6701 (closed by dhh). 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
Monitors stay black (0x0) when the PC boots with monitors powered off — they never recover
Summary
When the PC boots while the monitors are powered off (AC cut — e.g. smart power strip: the PC powers on automatically when power returns, but the monitors don't), Hyprland detects the monitors with partial EDID (make/model/physical size, no video modes). The monitors are created at width=0 height=0. When the monitors are powered on later, the session never recovers: black screens until reboot (or manual hyprctl reload).
Environment
- Omarchy quattro:
omarchy-dev 4.0.0.r1046.gd570d99-1 - Hyprland
0.56.0-2(installed Jul 27, while still on 3.8.4 — see note below) - Kernel
7.1.6-1-cachyos - GPU: AMD RX 6600 XT (amdgpu, navi23)
- Monitors: 3x Samsung "SAC DP1" 2560x1440 (DP-1 center, DP-2/DP-3 sides)
Reproduction
- Cut AC power to the monitors (smart strip off); PC stays on / power returns and the PC boots itself.
- The PC boots with the monitors unpowered.
- Power the monitors on manually (minutes later).
- Result: black screens. The graphical session started fine (uwsm/Hyprland OK, no errors), but the monitor is stuck at 0x0.
Evidence
hyprctl monitors -j after booting with monitors in standby:
{
"id": 0,
"name": "DP-1",
"description": "SAC DP1 0000000000000",
"make": "SAC",
"model": "DP1",
"width": 0,
"height": 0,
"physicalWidth": 700,
"physicalHeight": 390,
...
}modesis empty/null: the partial EDID the monitor reports in standby has no video modes →mode = "preferred"fails → monitor 0x0.- The connector never disconnects at the DRM level: no `monitoradded`/`monitorremoved` events fire when the monitor is powered on → Hyprland never re-reads the EDID → 0x0 permanently.
- With the monitors powered on before booting: everything works (same config).
Workaround (what we use meanwhile)
A user-level watcher that every 3s looks for enabled monitors with width == 0 and runs hyprctl reload (plus explicit hl.monitor re-apply if the reload isn't enough). When the user powers the monitors on, the screens appear within ~3s. No reboot needed.
Version note
This did not happen on 3.8.4 (Hyprland 0.55.4). The monitor config is identical between versions. Hyprland 0.56.0 and kernels 7.1.4/7.1.6 landed right before/during the migration. We suspect the change is in how Hyprland's DRM backend treats a "connected" connector with an EDID that has no modes (previously: treated as not connected → hotplug on wake → recovery; now: a permanent 0x0 monitor).
Suggestion
omarchy-hyprland-monitor-watch only recovers internal monitors (clamshell). An equivalent mechanism for external monitors (detect 0x0 and re-apply monitors.lua) would fix this natively.
View raw text
# Monitors stay black (0x0) when the PC boots with monitors powered off — they never recover
## Summary
When the PC boots while the monitors are powered off (AC cut — e.g. smart power strip: the PC powers on automatically when power returns, but the monitors don't), Hyprland detects the monitors with partial EDID (make/model/physical size, **no video modes**). The monitors are created at `width=0 height=0`. When the monitors are powered on later, the session **never recovers**: black screens until reboot (or manual `hyprctl reload`).
## Environment
- Omarchy quattro: `omarchy-dev 4.0.0.r1046.gd570d99-1`
- Hyprland `0.56.0-2` (installed Jul 27, while still on 3.8.4 — see note below)
- Kernel `7.1.6-1-cachyos`
- GPU: AMD RX 6600 XT (amdgpu, navi23)
- Monitors: 3x Samsung "SAC DP1" 2560x1440 (DP-1 center, DP-2/DP-3 sides)
## Reproduction
1. Cut AC power to the monitors (smart strip off); PC stays on / power returns and the PC boots itself.
2. The PC boots with the monitors unpowered.
3. Power the monitors on manually (minutes later).
4. Result: black screens. The graphical session started fine (uwsm/Hyprland OK, no errors), but the monitor is stuck at 0x0.
## Evidence
`hyprctl monitors -j` after booting with monitors in standby:
```json
{
"id": 0,
"name": "DP-1",
"description": "SAC DP1 0000000000000",
"make": "SAC",
"model": "DP1",
"width": 0,
"height": 0,
"physicalWidth": 700,
"physicalHeight": 390,
...
}
```
- `modes` is empty/null: the partial EDID the monitor reports in standby has no video modes → `mode = "preferred"` fails → monitor 0x0.
- The connector never disconnects at the DRM level: **no `monitoradded`/`monitorremoved` events fire** when the monitor is powered on → Hyprland never re-reads the EDID → 0x0 permanently.
- With the monitors powered on before booting: everything works (same config).
## Workaround (what we use meanwhile)
A user-level watcher that every 3s looks for enabled monitors with `width == 0` and runs `hyprctl reload` (plus explicit `hl.monitor` re-apply if the reload isn't enough). When the user powers the monitors on, the screens appear within ~3s. No reboot needed.
## Version note
This did not happen on 3.8.4 (Hyprland 0.55.4). The monitor config is identical between versions. Hyprland 0.56.0 and kernels 7.1.4/7.1.6 landed right before/during the migration. We suspect the change is in how Hyprland's DRM backend treats a "connected" connector with an EDID that has no modes (previously: treated as not connected → hotplug on wake → recovery; now: a permanent 0x0 monitor).
## Suggestion
`omarchy-hyprland-monitor-watch` only recovers internal monitors (clamshell). An equivalent mechanism for external monitors (detect 0x0 and re-apply `monitors.lua`) would fix this natively.
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.
No decision has been recorded yet.