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-4552GitHub issuePublicReceived

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.

Received and recorded verbatim. Nothing has been checked yet.

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 PC boots with monitors off — never recover on wakerevision 1 · captured 2026-10-04 11:56 UTC via poll

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:

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

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.