# Default `hypridle.conf` triggers display-controller wedge on AMD Phoenix/HawkPoint iGPUs

## Summary

The default `config/hypr/hypridle.conf` shipped by Omarchy invokes `omarchy-system-lock` without `OMARCHY_LOCK_ONLY=true` on the idle-lock listener (`timeout = 152`). That codepath ultimately calls `hyprctl dispatch dpms off`, which on AMD Phoenix (Ryzen 7040U) and HawkPoint (Ryzen 8040U/HS) iGPUs reliably wedges the display controller via the `optc314_disable_crtc` REG_WAIT timeout in `amdgpu`. The display will not wake again — the system must be hard-reset, which on btrfs filesystems often results in the volume being remounted read-only and downstream EROFS errors (e.g. Claude Code crashing on `~/.claude.json`).

The maintainers already gate `before_sleep_cmd` with this same env var, indicating awareness that the brightness-off / DPMS-off path is unsafe in some contexts. This issue proposes extending the same gate to the idle-lock listener so users on affected hardware aren't broken by default.

## Affected hardware

- AMD Phoenix / HawkPoint / HawkPoint Refresh iGPU (gfx1103, "Radeon 780M / 760M / 740M")
- Confirmed on Beelink SER8 (Ryzen 7 8845HS). Same family in: GMKtec NucBox K8/K9, Minisforum UM780/UM790, Asus NUC 14 Pro, Acemagic AMR5, Framework 13 AMD, and Ryzen 7040/8040 laptops generally.
- Kernel 6.6 through 7.0.3 (latest at time of filing) all reproduce.

## Symptom

User leaves the machine idle past the 152 s timeout. `omarchy-system-lock` runs without `OMARCHY_LOCK_ONLY=true`, so after locking it sleeps 3 s and runs:

```
omarchy-brightness-keyboard off
omarchy-brightness-display off    # → hyprctl dispatch dpms off
```

`amdgpu` then logs:

```
amdgpu 0000:65:00.0: [drm] REG_WAIT timeout 1us * 100000 tries - optc314_disable_crtc line:145
```

The display controller fails to disable cleanly; subsequent input does not wake the screen. The kernel does not OOPS or panic — it's a silent display-controller hang, so `journalctl` has no error trail. Only recovery is the power button.

## Evidence this is not isolated to Linux

A Beelink SER8 8845HS user on **Windows 10** reports the same wake-failure symptom: <https://bbs.bee-link.com/d/10367-ser8-8845hs-sleep--hibernate-problem/2>. They tried every driver/firmware combination including the BIOS revision Omarchy users would have (V035, still latest). This points at a firmware/HDMI-handshake bug on the platform itself — but Omarchy can avoid *triggering* it by not calling `dpms off` on hardware that's known to misbehave.

Upstream amdgpu reports on the same `optc1`/`optc314` family:
- <https://gitlab.freedesktop.org/drm/amd/-/issues/3368>
- <https://gitlab.freedesktop.org/drm/amd/-/issues/3922>

## Proposed change

Match the existing `before_sleep_cmd` pattern on the idle-lock listener in `config/hypr/hypridle.conf`:

```diff
 listener {
     timeout = 152
-    on-timeout = omarchy-system-lock
+    on-timeout = OMARCHY_LOCK_ONLY=true omarchy-system-lock
     on-resume = omarchy-system-wake
 }
```

This makes `omarchy-system-lock` skip the brightness-off block (lines 23-28 of the script). The lock screen still kicks in at 152 s; only the DPMS-off / brightness-off side effects are suppressed.

## Trade-off

Users on safe hardware lose the "screen brightness drops to 0 after idle-lock" power-saving behavior. The display stays at normal brightness behind the lock screen until the monitor's own DPMS / screen saver kicks in. On laptops this measurably hurts battery life on idle; on desktops it's negligible.

Possible refinements (open to discussion):

1. **Apply universally** (simplest) — the patch above. Trades a small power-save feature for not-bricking-affected-hardware-by-default.
2. **Gate by GPU detection** — check `lspci -nn | grep "VGA.*Radeon.*[78]40M"` or `/sys/class/drm/card*/device/device` for the affected IDs and apply the prefix conditionally. More complex but no functionality loss on safe hardware.
3. **Add a documented opt-out** — keep current default but add a one-liner to `omarchy-faq` or the README pointing AMD users at `OMARCHY_LOCK_ONLY=true` and explaining the symptom. Cheapest but relies on users finding the doc *after* the first crash.

I'd lean toward (1) for minimum complexity, but happy to write (2) or (3) if the maintainers prefer.

## Background / reproduction

For maintainers without affected hardware, this is reliably reproducible by:

1. Boot any Ryzen 7040/8040 desktop on Wayland/Hyprland with a single HDMI monitor.
2. Default Omarchy hypridle config (lock listener uncommented).
3. Walk away for 5+ minutes. Sometimes happens on first idle, sometimes after several hours of uptime.
4. Return: screen stays black. Mouse/keyboard input does not wake it. SSH from another machine *does* work — the OS is alive, only the display controller is wedged.

The 2026-05-19 cross-OS Beelink forum thread linked above is the cleanest external confirmation that this is a platform-level issue exacerbated by — not caused by — the DPMS-off call.

Happy to provide journalctl excerpts, hyprctl monitor state, or further repro detail if helpful.