### System details

ASUS laptop, Ryzen 9 8945HS, RTX 4060 Laptop (nvidia-open-dkms 610.57.04) + AMD 780M, Samsung Odyssey G9 5120x1440@240 over USB-C DP-alt, Omarchy 4.0.3-1, kernel 7.2.3-arch1-3, Hyprland 0.56.2-2, aquamarine 0.15.0-2

### What's wrong?

**Same root cause as #11019 (aquamarine 0.15.0, hyprwm/aquamarine#386), with a much more common trigger, on NVIDIA: pressing the power button on a single external monitor.**

I'm filing this separately because the fix has to come from Omarchy for now. Upstream auto-closed the fix PR, hyprwm/aquamarine#395, because its author isn't vouched, and no maintainer has responded in the four days since, so no fixed aquamarine release is coming soon. Every Omarchy 4.0.3 user who turns off, unplugs, undocks, suspends or DPMS-sleeps an external display is exposed. The reports in hyprwm/aquamarine#386 cover i915, xe and amdgpu; this adds nvidia-drm.

### Repro

1. Omarchy 4.0.3 with aquamarine 0.15.0-2. One external monitor is the only enabled output (both eDP connectors report disconnected).
2. Turn the monitor off with its power button and wait about 10 seconds.
3. Turn it back on. It shows "No Signal" and never recovers. Only a reboot brings it back.

All 3 attempts on 2026-09-10 needed a reboot. For the four weeks before the 2026-09-09 update (aquamarine 0.14.0-2, same NVIDIA driver), power-cycling this monitor never needed one.

### What the machine reports while the screen is black

- `hyprctl monitors`: DP-1 at 5120x1440 with `dpmsStatus: 1`.
- `/sys/class/drm/card1-DP-1/status` is `connected` and `enabled` is `enabled`.
- There is no EINVAL and no `0x0` output, so on nvidia-drm the failure is silent. One of the three attempts also logged `nvidia-modeset: WARNING: GPU:0: Lost display notification`, followed by an NVRM `GSP task watchdog timeout` report.

Hyprland log across the power-off and power-on (aquamarine debug level):

```
drm: Connector DP-1 disconnected
ERR from aquamarine ]: drm: Cannot commit a disconnected output
drm: DP-1 is not connected, clearing stale crtc 200
drm: Ignoring a stale pf event, flip 92507 on crtc 200
drm: Connector 823 connection state: 1
drm: connected slot 0 crtc 200 assigned to DP-1
```

### Cause (checked against the Hyprland v0.56.2 and aquamarine v0.15.0 source)

1. On power-off, Hyprland's `CMonitor::onDisconnect` sets the output disabled and commits (`src/output/Monitor.cpp:499-501`).
2. aquamarine commit 9d6fed9 added guards that reject that commit because the connector already reads disconnected (`src/backend/drm/DRM.cpp:2497`, and `SDRMConnector::commitState` at line 2144). The kernel CRTC stays active with the old [email protected] mode.
3. On power-on, the monitor gets the same connector and the same CRTC back. `CDRMAtomicRequest::addConnector` only submits a modeset when the requested mode differs from the kernel's current `MODE_ID` (`src/backend/drm/impl/Atomic.cpp:257-266`, with `getCurrentMode()` at `DRM.cpp:1882`). The modes are identical, so no modeset is sent and the NVIDIA driver never retrains the DisplayPort link.

Steps 1 and 2 match #11019. Step 3 is my reading of why NVIDIA with a single SST output stays black silently instead of failing with EINVAL; I haven't traced it with `AQ_TRACE`.

### Why Omarchy's own recovery doesn't catch it

`omarchy-hyprland-monitor-watch` calls `omarchy-hyprland-monitor-modeless`, which only reloads Hyprland when an enabled monitor is `0x0`. Here the output keeps a valid 5120x1440 mode and DPMS 1, so recovery never runs. Cycling DPMS isn't a safe fallback on NVIDIA either: #10925 was closed after doing that during a retrain hung the compositor.

### What would fix it for Omarchy users now

Either of these, in order of preference:

1. **Ship aquamarine 0.15.0 with hyprwm/aquamarine#395 applied in the `[omarchy]` repo**, so it replaces `extra/aquamarine`. In hyprwm/aquamarine#386, three separate reporters confirmed the patch fixes it: two on Intel with MST docks and one on AMD over USB-C.
2. **Hold the Hyprland stack in `omarchy update`** at aquamarine 0.14.0-2, hyprland 0.56.2-1 and hyprtoolkit 0.5.4-4 until aquamarine ships a fix. All three have to move together, because 0.15.0 bumped the soname from `libaquamarine.so=13` to `=14`.

If an Omarchy maintainer is vouched with hyprwm, carrying #395 upstream would also unblock everyone.

### Workaround for affected users (the rollback is confirmed working in hyprwm/aquamarine#386)

```
cd /tmp
for p in a/aquamarine/aquamarine-0.14.0-2 h/hyprland/hyprland-0.56.2-1 h/hyprtoolkit/hyprtoolkit-0.5.4-4; do
  curl -fLO https://archive.archlinux.org/packages/$p-x86_64.pkg.tar.zst
  curl -fLO https://archive.archlinux.org/packages/$p-x86_64.pkg.tar.zst.sig
done
sudo pacman -U aquamarine-0.14.0-2-x86_64.pkg.tar.zst hyprland-0.56.2-1-x86_64.pkg.tar.zst hyprtoolkit-0.5.4-4-x86_64.pkg.tar.zst
```

Then add `IgnorePkg = aquamarine hyprland hyprtoolkit` under `[options]` in `/etc/pacman.conf` and reboot. Remove that line once a fixed aquamarine ships.

Related: #11019 (same cause, USB-C dock), hyprwm/aquamarine#386, hyprwm/aquamarine#395, hyprwm/aquamarine#391 (NVIDIA, different trigger), hyprwm/Hyprland#16183.

Investigated with AI assistance. The versions, log lines and sysfs values are copied from the affected machine.