## What happened

An external LG display (DP-7, "LG Electronics LG HDR 4K") stayed physically off / reported "no signal" after the idle-wake flow ran, even though `hyprctl monitors` continued to report `dpmsStatus: true` for it. Waking the system via mouse/keyboard did not restore the signal. All other connected monitors (eDP internal panel, a ViewSonic, and a Microstep OLED) woke normally.

## What was expected

All monitors should light back up when the system wakes from idle.

## Root cause (traced this session)

`omarchy-system-wake` calls `omarchy-brightness-display on`, which contains this optimization in `/usr/share/omarchy/bin/omarchy-brightness-display`:

```bash
elif [[ $step == "on" ]]; then
  # Skip the dispatch when every active display is already lit: a redundant
  # DPMS enable right after system resume forces another modeset, which blanks
  # the panel for a beat (visible flash at the unlock screen).
  hyprctl monitors -j 2>/dev/null | jq -e '[.[] | select(.disabled == false)] | length > 0 and all(.dpmsStatus)' >/dev/null 2>&1 && exit 0
  hyprctl dispatch 'hl.dsp.dpms({ action = "enable" })' >/dev/null 2>&1
  exit 0
fi
```

If Hyprland's own `dpmsStatus` for a given monitor becomes desynced from its actual hardware power state (i.e. Hyprland believes it's already on, `dpmsStatus: true`, while the panel is physically dark/no-signal), this check passes for *all* monitors and the script exits before ever sending the enable dispatch. The affected monitor is then permanently skipped on every subsequent wake, since the check keeps finding "everything already claims to be on."

In this session's `hyprland.log`, the DP-7 connector shows repeated:

```
ERR from aquamarine ]: atomic drm request: failed to commit: Invalid argument, flags:
```

around modeset/DPMS transitions. A failed atomic KMS commit appears able to leave Hyprland's internal `enabledState`/`dpmsStatus` believing a transition succeeded when the actual commit was rejected by the kernel — which is a plausible way `dpmsStatus` gets stuck `true` while the panel is dark.

## Confirmed fix / workaround

Manually forcing a real state transition (not a no-op "enable" while state is already `true`) restored the display immediately:

```bash
hyprctl dispatch 'hl.dsp.dpms({ action = "disable" })'
hyprctl dispatch 'hl.dsp.dpms({ action = "enable" })'
```

This bypasses the skip-optimization entirely and forces Hyprland to recommit the mode, which brought the LG panel back with a valid signal.

## Suggested fix

The skip-optimization in `omarchy-brightness-display` has no fallback for the case where Hyprland's `dpmsStatus` is desynced from actual monitor state. Possible options:
- Don't rely solely on `dpmsStatus` to decide whether to skip; also check something reflecting the actual DRM connector state per monitor.
- Add a periodic/occasional real state cycle even when `dpmsStatus` is already true, to self-correct desyncs.
- At minimum, since this leaves a monitor permanently stuck until a manual disable/enable cycle or full session restart, consider surfacing this state (or an easy recovery command) to the user.

## System details

- `omarchy version`: 4.0.4-1 (rc channel)
- `hyprctl version`: Hyprland 0.56.2, commit `efb50993780079460b0cbed1363e2166a2de1d9f`, built Aug 5 2026
- CPU: Intel Core Ultra 9 275HX
- GPU: hybrid — Intel Arrow Lake-S iGPU (i915/xe) + NVIDIA GeForce RTX 5070 Max-Q (nvidia)
- 4 monitors active: internal eDP, ViewSonic VX3276-QHD, Microstep MAG321UP OLED, LG HDR 4K (affected, DP-7)

Note: `omarchy debug --no-sudo --print` (referenced in the skill docs / older instructions) does not exist as a command on this `omarchy` version — `omarchy commands --all` has no `debug` entry, so I couldn't attach the standard diagnostic bundle. Happy to provide additional logs on request.

## Steps to reproduce

1. Have multiple monitors attached including an LG display, with a hybrid-GPU laptop.
2. Let the system idle long enough for `omarchy-system-lock`/DPMS-off to trigger, or otherwise reach a state where an atomic DRM commit failure occurs around a monitor's modeset (logged as `atomic drm request: failed to commit: Invalid argument` in `hyprland.log`).
3. Wake the system.
4. Observe: some monitors wake, but one (in our case the LG display) stays off / no signal, while `hyprctl monitors -j` still reports `dpmsStatus: true` for it.
5. `hyprctl dispatch 'hl.dsp.dpms({ action = "disable" })'` then `'hl.dsp.dpms({ action = "enable" })'` recovers it; a plain `enable` dispatch alone does not (no-op since state is already "true").