### System details

- Omarchy 3.8.3
- Hyprland 0.55.4, hyprlock 0.9.5, hypridle
- Kernel 7.1.3-arch1-2
- GPU: Intel iGPU + NVIDIA MX550 (hybrid)

### What's wrong?

The shipped default `config/hypr/hypridle.conf` sets the screensaver and lock listeners **2 seconds apart**, which effectively disables the screensaver, and the update also **overwrites a user-modified `~/.config/hypr/hypridle.conf`** (backing it up to `hypridle.conf.bak.<epoch>`). Filing the screensaver-timing + overwrite parts specifically because they don't appear to be tracked yet — the DPMS-off crash they interact with is already covered by #5910 and #6223 (see bottom).

**1. Screensaver is killed ~2s after it launches.** The default is:

```ini
listener {                                   # screensaver
    timeout = 150
    on-timeout = pidof hyprlock || omarchy-launch-screensaver
}
listener {                                   # lock, only 2s later
    timeout = 152
    on-timeout = omarchy-system-lock
    on-resume = omarchy-system-wake
}
```

At 150s the screensaver launches; at 152s `omarchy-system-lock` runs and does `pkill -f org.omarchy.screensaver`. So the screensaver is visible for ~2 seconds and then killed by the lock, i.e. the screensaver never really runs on the default. The inline comment ("screensaver resets idle timer, so have to just do half + 2s margin") suggests the 2s gap is a workaround for the screensaver resetting the idle timer — but the screensaver is a non-interactive terminal app and shouldn't be generating input events, so the net effect is just that the screensaver is defeated.

**2. `omarchy update` overwrites a user-modified `hypridle.conf`.** My customized file (which deliberately avoided `dpms off`, see below) was replaced by the default on update and backed up beside it. Hardware-specific workarounds get silently reverted, and the regression only surfaces hours later when the machine has been idle.

### Steps to reproduce (screensaver)

1. On a stock Omarchy 3.8.3 `hypridle.conf`, leave the machine idle.
2. At 2m30s the screensaver appears; ~2s later it's replaced by the lock screen.

### Why this compounds with the known DPMS crashes

The same `timeout = 152` lock listener calls `omarchy-system-lock` **without** `OMARCHY_LOCK_ONLY=true`, which reaches `omarchy-brightness-display off` → `hyprctl dispatch dpms off`. On my Intel+NVIDIA hybrid this crashed the compositor overnight (the Hyprland crash screen), which is the same failure class as:

- #5910 (Default `hypridle.conf` wedges display on AMD Phoenix/HawkPoint iGPUs — already identifies the exact `timeout = 152` / missing `OMARCHY_LOCK_ONLY=true` root cause and fix)
- #6223 (Crash/hard-freeze after `omarchy-system-lock` on kernel 7.1.3)

Adding this as a data point that the DPMS-off lock path is **not AMD-specific** — it also bites Intel+NVIDIA hybrid setups.

### Suggestions

- Widen the gap between the screensaver and lock timeouts (or drive lock off the screensaver's own lifetime) so the screensaver is actually visible.
- Gate the idle-lock listener with `OMARCHY_LOCK_ONLY=true` (as `before_sleep_cmd` already is), or prefer backlight-dim over `dpms off`, given the recurring DPMS crash reports.
- On update, avoid clobbering a user-modified `hypridle.conf` (detect divergence and skip / prompt / use a `.pacnew`-style side file).

### Config that works for me (screensaver visible, no DPMS-off)

```ini
general {
    lock_cmd = OMARCHY_LOCK_ONLY=true omarchy-system-lock
    before_sleep_cmd = loginctl lock-session
    after_sleep_cmd = sleep 1 && hyprctl dispatch dpms on
    inhibit_sleep = 3
}
listener { timeout = 600  on-timeout = pidof hyprlock || omarchy-launch-screensaver }
listener { timeout = 601  on-timeout = loginctl lock-session }
listener { timeout = 900  on-timeout = brightnessctl -sd '*::kbd_backlight' set 0  on-resume = brightnessctl -rd '*::kbd_backlight' }
listener { timeout = 900  on-timeout = brightnessctl -s set 0  on-resume = brightnessctl -r }   # dim, not dpms off
```