### System details

- Omarchy 4.0.3-1
- Hyprland 0.56.2-2
- Aquamarine 0.15.0-2
- Quickshell 0.3.1-1
- Mesa 26.2.2-1
- `linux-t2` 7.2.4
- Intel CoffeeLake-H UHD Graphics 630 (`i915`, `8086:3e9b`)
- Single active Philips 288E2 on `DP-3`, 3840x2160@60, scale 1.5, VRR off
- UWSM / Hyprland Lua configuration

### What's wrong?

After the external monitor has been idle or in power save for a long period, it can wake showing **No video input** even though the compositor, DRM sysfs and Hyprland all report a live output. SSH remains responsive and a controlled DPMS/modeset cycle restores the same session without rebooting or restarting Hyprland.

This has now occurred twice on the same long-running session: once during the evening and again the following morning after an overnight idle period. The machine did not suspend or hibernate overnight; uptime at the second occurrence was 3 days 14 hours.

At the morning occurrence, before recovery:

```text
/sys/class/drm/card1-DP-3/status  = connected
/sys/class/drm/card1-DP-3/dpms    = On
/sys/class/drm/card1-DP-3/enabled = enabled
```

`hyprctl -j monitors all` still reported:

```json
{
  "name": "DP-3",
  "width": 3840,
  "height": 2160,
  "refreshRate": 60.0,
  "scale": 1.5,
  "dpmsStatus": true,
  "disabled": false
}
```

The physical monitor nevertheless reported no input.

### Relevant logs

Aquamarine recorded a pending page-flip condition followed by connector churn:

```text
drm: Modesetting DP-3 with [email protected]
drm: Cannot commit when a page-flip is awaiting
drm: Cannot commit when a page-flip is awaiting
drm: Connector DP-3 disconnected
drm: Cannot commit a disconnected output
drm: connector DP-3, has crtc 59, will be rechecked
drm: Connector DP-3 connected
drm: Connecting connector DP-3, CRTC ID 59
drm: Modesetting DP-3 with [email protected]
```

During the morning incident, Quickshell repeatedly saw the sole output disappear:

```text
08:09:02 There are no outputs - creating placeholder screen
08:09:05 There are no outputs - creating placeholder screen
08:09:23 There are no outputs - creating placeholder screen
08:09:28 There are no outputs - creating placeholder screen
08:09:47 There are no outputs - creating placeholder screen
08:09:48 There are no outputs - creating placeholder screen
```

No matching i915 GPU hang, GPU reset, CRTC timeout, `flip_done timed out`, OOM or system suspend/resume event was present in the kernel/system journal.

### Recovery tested twice

The following recovery preserved the compositor and applications:

```bash
hyprctl dispatch "hl.dsp.dpms({ action = 'disable', monitor = 'DP-3' })"
sleep 3
hyprctl eval 'hl.monitor({ output = "DP-3", mode = "3840x2160@60", position = "0x0", scale = 1.5 })'
hyprctl dispatch "hl.dsp.dpms({ action = 'enable', monitor = 'DP-3' })"
```

After the reset:

- the physical image returned;
- DP-3 remained `connected`, `enabled`, and DPMS `On`;
- 3840x2160@60 and scale 1.5 were preserved;
- no new `There are no outputs` messages appeared during a 22-second check;
- the owner confirmed the monitor was visible again.

Sunshine was restarted afterward because its Wayland capture can retain the invalidated output, but Sunshine is not required to reproduce the physical no-signal state.

### Reproduction status

Intermittent. The observed trigger is a long idle/monitor-power-save period, not system suspend. A deterministic wait duration has not been isolated.

Expected: the monitor resumes receiving video, or the desktop detects the stalled scanout and performs one bounded recovery.

Actual: all software-visible state can say that DP-3 is active while the physical monitor has no video input. A manual DPMS/modeset cycle is required.

### Important diagnostic caveat

This session had already been modified while recovering a separate DDC issue:

- the stock `omarchy.monitor` bar entry was removed to stop the DDC polling problem documented in #6855;
- `omarchy-hyprland-monitor-watch` had been stopped during that earlier live recovery and was not running at the morning occurrence;
- the third-party `im0001gt.screens` plugin manages the persistent monitor rule, with profile auto-switch disabled.

Therefore this report does **not** claim that the packaged monitor watcher ran and failed. It documents the underlying Intel/i915 + Aquamarine 0.15 dark-output state and a tested recovery. It would still be useful to provide a supported manual recovery command, and potentially a bounded stalled-output recovery path that does not depend only on width/height or connector metadata.

### Related reports

- #9078: current modeless recovery cannot identify every dark output with valid metadata.
- #10852: similar active-output freeze recovered by DPMS on AMD; closed after Aquamarine 0.15 resolved that reporter's symptoms. This occurrence is on Intel/i915 with Aquamarine 0.15.0-2.
- #6855: separate DDC polling issue encountered earlier in the same session; the DDC panel was removed before this overnight recurrence.

No private network details, monitor serial, or application data are included.