### Summary

On this machine, Omarchy's lock/idle path can crash or wedge Hyprland when it turns the display off via DPMS. The affected display is an HKC GS49UK 49" ultrawide on DisplayPort (`DP-1`, `5120x1440@240`) with an NVIDIA RTX 5090 D.

I am intentionally not re-running the DPMS-off repro command right now because the previous failures required a forced reboot. The local workaround was to make locking use `OMARCHY_LOCK_ONLY=true` and to disable the idle DPMS-off path.

### What appears to be happening

Omarchy's current lock command says "Lock the computer and turn off the display" and eventually runs:

```bash
omarchy-brightness-display off
```

That command maps to:

```bash
hyprctl dispatch dpms off
```

On this HKC DisplayPort monitor, that appears to make the connector disappear/retrain. The Hyprland crash reports then show `DP-1` disconnecting and Hyprland crashing in the monitor-disconnect path.

So my best read is:

1. Omarchy triggers `dpms off` shortly after lock/idle.
2. The HKC GS49UK drops/retrains the DP signal.
3. Hyprland/Aquamarine sees `Connector DP-1 disconnected`.
4. Hyprland crashes while entering the unsafe/headless-output path.

### Crash evidence

Two local crash reports from 2026-06-18 show the same pattern:

```text
Hyprland received signal 11(SEGV)
Tag: v0.55.3
Release: 7.0.11-arch1-1
Aquamarine: built against 0.12.0, system has 0.12.0
GPU: NVIDIA GB202 [GeForce RTX 5090 D]

Desktop::View::getViewsForWorkspace(...)
Render::IHyprRenderer::sendFrameEventsToWorkspace(...)
Aquamarine::CHeadlessOutput::commit()
CCompositor::enterUnsafeState()
CMonitor::onDisconnect(bool)
...
DEBUG from aquamarine ]: drm: Connector DP-1 disconnected
```

### Local versions / timeline

Current Omarchy:

```text
Omarchy 3.8.2
omarchy repo: 8e031516 Fix compatibility of old tiling.conf with HL 0.55+
```

The Omarchy-side DPMS trigger appears to come from the 3.8-era lock/idle changes:

```text
ca74b4d1 Simplify but letting omarchy-system-lock be responsible for turning off display and keyboard brightness
6111ee13 Reduce screen off after system lock to 3s
4e4a688f Prevent flicker on waking from sleep
```

This machine applied the relevant migration locally on 2026-05-14:

```text
1778054328.sh: Use omarchy-system-lock and omarchy-system-wake in hypridle
```

The more recent graphics-stack update window before the crashes was:

```text
2026-06-05: nvidia-utils 595.71.05 -> 610.43.02
2026-06-05: nvidia-open-dkms 595.71.05 -> 610.43.02
2026-06-05: aquamarine 0.11.0 -> 0.12.0
2026-06-11: hyprland 0.55.2 -> 0.55.3
2026-06-18: crashes observed under Hyprland 0.55.3 / Aquamarine 0.12.0 / NVIDIA 610.43.02
```

After the crashes, the system was updated to:

```text
hyprland 0.55.4-1
aquamarine 0.12.1-1
hyprlock 0.9.5-4
hypridle 0.1.7-9
nvidia-utils 610.43.02-2
nvidia-open-dkms 610.43.02-2
linux 7.0.12.arch1-1
```

I have not re-tested DPMS-off on the updated stack because it is disruptive when it fails.

### Local workaround

This avoids the crash trigger locally:

```conf
lock_cmd = OMARCHY_LOCK_ONLY=true omarchy-system-lock
```

and the manual lock binding was changed to:

```conf
OMARCHY_LOCK_ONLY=true omarchy-system-lock
```

The idle DPMS-off listener was also disabled locally.

### Why I am opening this here

This may ultimately be a Hyprland/Aquamarine/NVIDIA crash bug, but Omarchy's default lock/idle path is what triggers the unsafe `dpms off` transition. There are already related reports where removing DPMS-off avoids hard failures:

- https://github.com/basecamp/omarchy/issues/2635
- https://github.com/basecamp/omarchy/issues/5910
- https://github.com/basecamp/omarchy/issues/1147
- https://github.com/hyprwm/Hyprland/issues/15062

It would help if Omarchy exposed a supported way to lock without powering off displays, or made the DPMS-off behavior opt-in / configurable for hardware that does not tolerate this transition.