### System details

Beelink/AZW GTR Pro, AMD Strix Halo GPU `1002:1586` using amdgpu; Omarchy `4.0.2-1`, kernel `7.1.9-arch1-2`, Hyprland `0.56.2-1` (`efb50993780079460b0cbed1363e2166a2de1d9f`), Aquamarine `0.14.0-2`, Mesa `26.2.1`, linux-firmware-amdgpu `20260810-2`. BIOS GTRP107 dated 2025-08-22. Samsung Odyssey G91SD, sole active output DP-3, 5120×1440 at 143.987 Hz, RGB 8-bit, DSC active. VRR, direct scanout and tearing disabled. Lua config, UWSM. **Video is connected directly from the PC to the monitor; it does not pass through the KVM.** A KVM is used for USB peripherals.

### What's wrong?

The sole display froze during normal desktop use, while SSH, Hyprland IPC and GPU rendering work remained responsive. Kernel scanout stopped progressing. The output retained a valid mode **and an active CRTC** throughout the captured freeze, so Omarchy's modeless-monitor recovery probe returned 1 and could not recognize this state. A manual DPMS off/on cycle restored the same compositor and applications.

This extends the recovery problem in #9078 with a captured case that also passes its proposed active-monitor-list check: DP-3 appeared in both ordinary `hyprctl monitors` and `monitors all`, with an enabled/active DRM CRTC. The original kernel failure is being reported upstream separately; this report concerns the failure to recover a stranded output in the packaged desktop stack.

Upstream report with the complete scheduling analysis: [hyprwm/aquamarine#390](https://github.com/hyprwm/aquamarine/issues/390).

#### Reproduction status and expected behavior

Intermittent; a deterministic trigger has not been isolated. On September 7, 2026, after approximately 2 days 21 hours of uptime, the desktop stopped updating during ordinary use. There was no intentional suspend/restart or diagnostic intervention before the initial freeze. The KVM was switched at 17:07:12 PDT, after the last measured vblank at 17:06:03 and the kernel timeout at 17:06:13. The video cable bypasses the KVM; USB switching alone is not established as a trigger.

Expected: the output keeps updating, or a failed output can recover without losing the running session. Actual: valid monitor metadata continued to be reported while display updates and screencopy remained stuck, until a manual power-state cycle.

#### Captured evidence

```text
17:06:13.706267 amdgpu 0000:c4:00.0: [drm] *ERROR* [CRTC:424:crtc-0] flip_done timed out
```

Four consecutive `drmCrtcGetSequence()` samples returned sequence `4271800` with the same timestamp `250474841152381`. DRM state showed CRTC 424 enabled and active, attached to connector 461 / DP-3. Relevant IPC fields were:

```json
[{"name":"DP-3","width":5120,"height":1440,"refreshRate":143.987,"dpmsStatus":true,"disabled":false,"vrr":false,"currentFormat":"XRGB8888"}]
```

There were 44 GiB available RAM, zero swap use and zero recent memory PSI. No associated OOM, GPU ring timeout or GPU reset was found. Graphics fences continued advancing. Hyprland's main thread was in `epoll_wait` through the Wayland event loop and IPC answered immediately. `grim` timed out after 8 seconds while frozen.

A privately retained process core, inspected using types compiled from the installed Aquamarine headers, showed:

```text
CDRMOutput: name="DP-3", enabledState=true, needsFrame=true
SDRMConnector: szName="DP-3", id=461
sched.m_pending=true
sched.m_frameScheduled=false
sched.m_frameRunning=false
```

This documents the stuck scheduling state; it does not establish the original driver/firmware trigger or prove an Omarchy-specific cause.

#### Tested recovery workaround

Executed over SSH against the existing session, using the installed Lua dispatcher:

```bash
hyprctl -i 0 dispatch 'hl.dsp.dpms({action="off", monitor="DP-3"})'
sleep 2
hyprctl -i 0 dispatch 'hl.dsp.dpms({action="on", monitor="DP-3"})'
```

Off returned `ok` at 17:14:13; on was issued at 17:14:15 and returned IPC timeout/exit 6 after about 5.3 seconds while the compositor continued. Further kernel CRTC/plane commit timeouts appeared at 17:14:23, 17:14:33 and 17:14:44. By the end of that interval, sequence samples advanced (`4346743`, `4346870`, `4347016`, `4347160`), screencopy succeeded and the display visibly woke up. Hyprland kept PID 1644 and applications remained open. An IPC timeout alone therefore did not mean the recovery request had failed.

This is a tested recovery from one captured incident, **not** a permanent prevention fix. The command must target an existing physical output; it cannot restore a monitor that the kernel reports disconnected.

#### Tests of the recovery detection gap

I ran the installed `omarchy-hyprland-monitor-modeless` script with a temporary `hyprctl` fixture command on PATH, feeding it the saved monitor JSON and control fixtures. This executes the actual installed probe without changing the live display.

| Input | Actual exit code | Interpretation |
| --- | --- | --- |
| Full saved JSON from the frozen, active DP-3 | 1 | Not modeless; `recover_modeless()` stops if invoked |
| Healthy enabled output with a valid mode | 1 | Not modeless |
| Enabled output at 0×0 | 0 | Modeless; eligible for recovery |
| Intentionally disabled output at 0×0 | 1 | Correctly ignored |
| Only the virtual FALLBACK monitor at 1920×1080 | 1 | Not modeless; does not imply a physical display exists |

The probe correctly implements its narrow name, but that state is insufficient as a broader recovery decision. Also, `omarchy-hyprland-monitor-watch` triggers recovery from monitor/config events, so a stalled-but-still-present output need not generate an event that starts a recovery attempt at all. Broadening only the width/height predicate cannot detect this incident.

#### Proposed fix direction and regression coverage

A separate, bounded stalled-output recovery path would need a stronger signal, such as the matching kernel flip timeout plus a connected, powered-on output and repeated evidence that scanout is not progressing. It could capture evidence and arrange one controlled DPMS/modeset recovery with backoff, while preserving existing modeless-monitor handling. A manual recovery command/documented SSH procedure is immediately useful. Automatic recovery is **not** implemented or validated by this report.

Regression coverage should preserve the existing 0×0 behavior; distinguish a captured active-CRTC stall from a healthy output; avoid resetting deliberately powered-off, disabled, disconnected, headless or VRR-idle outputs; handle IPC timeouts during successful recovery; and prevent repeated reset loops. The table above contains completed detection tests; the automatic-recovery tests are proposed work. No repository source patch is included, and `./test/all` was not run because no Omarchy source code was changed.

#### Diagnostics and related reports

`omarchy debug --no-sudo --print` was collected locally. The relevant version, monitor, kernel, thread and resource diagnostics are included above. Unrelated network/environment information and application memory were omitted from the public report. A frozen screenshot was unavailable because the screencopy request itself timed out. The private raw core and desktop screenshots have not been uploaded.

Related: #9078 (valid mode but missing CRTC), #7874 (NVIDIA freeze on similar userspace versions), and [Aquamarine #343](https://github.com/hyprwm/aquamarine/issues/343) (pending page-flip/deadlock reports). This AMD capture has a kernel timeout, responsive IPC and an active CRTC; these reports are not asserted to share one root cause.

A separate September 8 no-signal incident showed DP-3 disconnected at kernel level and only a virtual FALLBACK monitor, without a new flip timeout. The connector returned at 11:13:33 PDT before a later config reload, after which frame progression and successful screencopy were verified and the owner confirmed recovery. It is not counted as another reproduction of this active-CRTC stall. Aquamarine v0.15.0 is now available with relevant page-flip/hotplug changes, but this hardware has only been tested on packaged v0.14.0.

Prepared with Codex from live diagnostics on the affected machine, reviewed against the saved evidence, and submitted with the machine owner's authorization.