### System details

Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy, Hyprland 0.56.2-2, aquamarine 0.15.0-2, nvidia-580xx-dkms 580.178.04-1.1. AMD Ryzen 7 5800X, MSI MAG B550 TOMAHAWK MAX WIFI, Gigabyte RTX 4070.

Monitors, all connected at boot:

- DP-2 Samsung S34CG50, 3440x1440@100
- DP-1 Samsung S34CG50, 3440x1440@100
- DP-3 LG UltraGear, [email protected]
- HDMI-A-1 Dell S2340M, 1920x1080@60

Debug log (taken after the outputs were restored, so `inxi` shows the full modes): https://logs.omarchy.org/YOeAXY

### What's wrong?

The three DisplayPort screens stay black. Hyprland reports them as 0x0. HDMI keeps working. The connectors stay connected, link-status is Good, and `hyprctl monitors all` lists every EDID mode, so this is not the partial-EDID case the modeless watcher is written for.

`omarchy-hyprland-monitor-watch` detects the 0x0 outputs and its only recovery is `hyprctl reload`. Reload reapplies the same monitor rules, the atomic commit is rejected again, and the screens stay black. The loop backs off to 60s and keeps doing that.

**Expected:** Outputs that already have a full mode list and a live kernel mode come back. A reload that repeats a commit the kernel is rejecting does not do that.

**What Hyprland logged at session start:**

```
drm: Modesetting DP-1 with [email protected]
drm: Cannot commit when a page-flip is awaiting
drm: Modesetting DP-2 with [email protected]
drm: Cannot commit when a page-flip is awaiting
drm: Modesetting DP-3 with [email protected]
drm: Cannot commit when a page-flip is awaiting
drm: Disabling output DP-1
drm: DP-1 is disabled, releasing crtc 83
```

The same "page-flip is awaiting" refusal happened for HDMI. HDMI came back. The DisplayPort outputs did not.

That commit never reached the kernel, but Aquamarine still dropped the CRTC in its own state. debugfs still showed the old mapping, with Hyprland framebuffers on the primary planes:

- HDMI-A-1 on crtc-0, active=1
- DP-1 on crtc-1, active=1, 3440x1440
- DP-2 on crtc-2, active=1, 3440x1440
- DP-3 on crtc-3, active=1, 2560x1440

**What the kernel logged on every later modeset, including the ones from `hyprctl reload`:**

```
[drm:drm_atomic_helper_check_modeset] [CRTC:83:crtc-1] enabled/connectors mismatch (1/0)
[drm:drm_atomic_check_only] atomic driver check failed: -22
```

The other two DisplayPort CRTCs failed the same way (`(1/0)` when a commit left a CRTC enabled with no connector, `(0/1)` when it disabled a CRTC that still had one). Aquamarine then walks every mode on the connector. All of them fail TEST_ONLY, so the output stays 0x0. Setting `ACTIVE=0` does not clear this. `enable` follows `MODE_ID`, and the orphaned CRTC is no longer in Hyprland's commit because Hyprland already released that id.

**Modeless detection misses the stuck-disabled case.** `omarchy-hyprland-monitor-modeless` only treats an output as modeless when `disabled != true` and the size is 0x0. After a failed disable the output is `disabled=true` at 0x0, the check exits 1, and `recover_modeless` stops.

**What recovered this session:** An atomic commit that set `CRTC_ID=0` on each DP connector and `MODE_ID=0` on those CRTCs, leaving HDMI alone. After the kernel CRTCs were actually off, `hl.monitor` with `disabled=false`, 60Hz, `supports_hdr=0`, and `supports_wide_color=0` modeset each output, and the native rate then applied. All four are scanning out again.

Forcing connector status off/on in sysfs made the desync worse. Hyprland treated the hotplug as a new connect and assigned a free CRTC while the kernel still had the old one enabled.

The same 0x0 DisplayPort failure happened on this machine earlier today on NVIDIA 610.57.04. This report is from the 580.178.04 boot, which is the one where the CRTC mismatch was traced.