## Lock screen wakes in a loop on monitors that drop HDMI hotplug in standby

### System details

- **Omarchy:** 4.0.4-1
- **Kernel:** 7.2.5-3-omarchy
- **Hyprland:** 0.56.2
- **Quickshell:** 0.3.1-1
- **CPU:** AMD Ryzen 9 5900X
- **GPU:** AMD Radeon RX 550 (Lexa PRO, amdgpu)
- **Monitor:** Philips 278E1 (27" 4K) on HDMI-A-1. I saw the same behavior before on an Acer monitor, and it was worse there.

### What happens

While the session is locked, the display keeps turning on and off. Each time it comes back it shows the password field for a few seconds, then goes dark again. This repeats for as long as the machine stays locked.

### Expected

After the lock blanks the display, it stays off until real keyboard or mouse input.

### Steps to reproduce

1. Use a monitor that drops its HPD line when it goes into standby. Many HDMI monitors do this.
2. Lock with `omarchy system lock`, or let the idle timeout lock the session.
3. Don't touch anything.

After about 5 s `idleBlankTimer` fires and runs `omarchy-brightness-display off`, which disables DPMS. A few seconds later the display wakes up showing the lock UI, and the cycle starts over.

### What the logs show

The Hyprland log (`$XDG_RUNTIME_DIR/hypr/*/hyprland.log`) has dozens of back-to-back disconnect/reconnect pairs for the output while locked:

```
drm: Got a hotplug event for /dev/dri/card1
drm: Connector HDMI-A-1 disconnected
ERR from aquamarine ]: drm: Cannot commit a disconnected output
drm: HDMI-A-1 is not connected, clearing stale crtc 67
drm: Got a hotplug event for /dev/dri/card1
drm: Connector HDMI-A-1 connected
drm: Modesetting HDMI-A-1 with [email protected]      <- panel lights up with the lock UI
...
drm: Disabling output HDMI-A-1                        <- blanked again
drm: Got a hotplug event for /dev/dri/card1           <- monitor enters standby, drops HPD, loop repeats
```

### Suspected cause

1. The lock blanks the display (DPMS off). The monitor gets no signal, goes into standby and drops HPD.
2. Hyprland removes the output and adds it back. The re-added output comes up with DPMS **on** and gets a full modeset.
3. Quickshell recreates the `WlSessionLockSurface` for the new output. The pointer "enters" the new surface, so the `MouseArea` in `plugins/lock/LockView.qml` fires `onPositionChanged` -> `wakeRequested()` -> `runWake()`, which runs `omarchy-system-wake` and re-arms `idleBlankTimer`.
4. 5 s later the display is blanked again, and the loop continues from step 1.

So the lock treats an output hotplug as user activity, and a newly added output ignores the fact that the lock had already blanked the screens.

### Suggested fix

- While the lock is in the blanked state, don't let an output being added or the lock surface being recreated count as activity. For example, ignore pointer enter / position changes that come with no real motion, or suppress wake for a short grace period after `Quickshell.onScreensChanged`.
- When an output is (re)added while locked and blanked, keep it or put it back in DPMS off instead of leaving it on.

### Workaround

Pin each connected connector's EDID at boot through debugfs `edid_override`, then set `/sys/class/drm/cardN-<connector>/status` to `on`. amdgpu then emulates the link while the monitor sleeps and no disconnect reaches the compositor. It works, but it needs root and a system service, and it breaks hot-swapping monitors on that port until the next reboot.