## Current investigation status

**Latest: long physical standby/wake now succeeds on the unpatched stack. No hidden active local fix was found in the completed source/configuration audit. The cause of the changed behavior remains unknown. Investigation is paused pending recurrence; this issue remains open, not confirmed fixed.** See the [latest test and audit results](https://github.com/omacom/omarchy/issues/11066#issuecomment-5621491100).

The original DPMS opt-out below is a workaround, not the accepted standby/wake fix. A local Aquamarine `dpmsfix3` candidate now passes offline regression tests, including a run against the packaged library, but is not installed or hardware-verified. Failed KMS cleanup can still permit premature CRTC reuse; concurrency and callback coverage gaps remain. See the [detailed progress update](https://github.com/omacom/omarchy/issues/11066#issuecomment-5619287755). PR #11072 remains a draft and must not be merged as this issue's resolution. The Aquamarine #337 reference below is historical, not evidence of the same root cause; the closer cleanup-regression report is [Aquamarine #386](https://github.com/hyprwm/aquamarine/issues/386).

---

## Bug description

Omarchy's lock service unconditionally runs `omarchy-brightness-display off` five seconds after locking. On a DisplayPort MST connection, that DPMS-off can remove the only output. With the current Aquamarine/Hyprland stack, the display reconnects under a new connector name but cannot be modeset again. The machine remains running with a black screen until reboot.

This is a verified regression on an Apple Mac Pro 6,1 with dual FirePro D700 GPUs and an ASUS PA329CRV connected over DisplayPort/MST.

## Steps to reproduce

1. Use the system with the ASUS PA329CRV active as `DP-13` at 3840x2160@60.
2. Lock the session, or wait for Omarchy's configured idle lock.
3. Wait five seconds for `idleBlankTimer` in `shell/plugins/lock/Service.qml` to run `omarchy-brightness-display off`.
4. Press a key or attempt to unlock.

## Expected behavior

The display wakes and the lock screen remains usable.

## Actual behavior

The MST topology stops and restarts. The original output disappears:

```text
kernel: [drm] DM_MST: stopping TM on aconnector ... [id: 118]
wayvnc: Selected output DP-13 went away
omarchy-shell: There are no outputs - creating placeholder screen
kernel: [drm] DM_MST: starting TM on aconnector ... [id: 118]
kernel: [drm] DM_MST: DP12, 4-lane link detected
```

Aquamarine enumerates the reconnected monitor as `DP-14`, but Hyprland reports it as active with `width: 0`, `height: 0`. DPMS enable and `hyprctl reload` do not recover it. The Hyprland log then repeats:

```text
atomic drm request: failed to commit: Invalid argument, flags: ATOMIC_ALLOW_MODESET ATOMIC_TEST_ONLY
```

A reboot restores the same physical monitor as `DP-13`, 3840x2160@60, scale 1.6.

## Environment

- Omarchy: `omarchy-dev 4.0.0.r2092.g5ead870-1`
- Hyprland: `0.56.2-2`
- Aquamarine: `0.15.0-2`
- Kernel: `7.2.4-arch1-2`
- Mesa: `26.2.2-1`
- GPU: 2x Apple FirePro D700 / AMD Tahiti XT, `amdgpu`
- Monitor: ASUS PA329CRV, DisplayPort MST

The failure started after the 2026-09-09 update that included Aquamarine `0.14.0-2 -> 0.15.0-2`, Hyprland package `0.56.2-1 -> 0.56.2-2`, and Linux `7.1.9 -> 7.2.x`.

## Proposed Omarchy-side fix

Make lock-screen display blanking configurable instead of unconditional, for example:

```json
{
  "idle": {
    "screensaver": 150,
    "lock": 300,
    "blankDisplay": false
  }
}
```

When disabled, keep locking and authentication behavior unchanged but skip `omarchy-brightness-display off`. This gives affected DP/MST systems a supported workaround without modifying package-owned QML.

I verified the workaround locally by shadowing `omarchy-brightness-display` and making only the `off` action a no-op. The session still locks, the lock shell still wakes normally, and DPMS remains enabled (`true -> true`).

A related Aquamarine failure signature is documented in [hyprwm/aquamarine#337](https://github.com/hyprwm/aquamarine/issues/337), where a DP/MST atomic `TEST_ONLY` commit also fails with `EINVAL`.