## hyprlock crashes with ABRT after suspend/resume — "Oopsie daisy" recovery screen on Dell Vostro 7620 (Intel only)

### System details

- **Omarchy version**: 3.8.1
- **Hardware**: Dell Vostro 7620 (Intel-only SKU, no dGPU)
- **GPU**: Intel Iris Xe Graphics (ADL GT2, `8086:46a6`)
- **Driver**: i915 + Mesa 26.0.6-arch1.1
- **Kernel**: 7.0.3-arch1-2
- **hyprlock**: v0.9.5
- **Docking**: Always docked (HDMI external monitor + power cord). Lid usually closed while docked, triggering suspend/resume cycles.

### What's wrong?

After lid close → suspend → open lid → resume, hyprlock crashes with `SIGABRT` (signal 6) ~1 second after `PM: suspend exit`. Hyprland then shows the **"Oopsie daisy, it looks like you locked your screen but the lockscreen app died"** recovery screen.

The session remains locked but cannot be unlocked — TTY switch + `hyprctl` recovery is required every time.

### Steps to reproduce

1. Close laptop lid (or `systemctl suspend`)
2. Wait for system to enter S3 sleep
3. Open lid
4. System resumes, but hyprlock crashed — locked out

### Journal timeline

```
18:11:54  kernel: Freezing user space processes
18:11:54  kernel: OOM killer disabled.
18:11:54  kernel: ACPI: EC: interrupt blocked
18:11:54  kernel: ACPI: EC: interrupt unblocked
18:11:54  kernel: spd5118 14-0050: PM: failed to resume async: error -6
18:11:54  kernel: i915 0000:00:02.0: GT0: GuC firmware i915/adlp_guc_70.bin v70.49.4
18:11:54  kernel: i915 0000:00:02.0: GT0: GUC: submission enabled / SLPC enabled / RC enabled
18:11:54  kernel: PM: suspend exit
18:11:54  uwsm_hyprland.desktop: error in client communication (pid 518865)
18:11:55  coredump: hyprlock terminated with SIGABRT, dumped core
```

### Hyprland compositor log (current session)

The compositor logs the client disconnection via UWSM but does not log the "Oopsie daisy" overlay message (it is rendered on-screen only):

```
May 21 18:11:55 [hostname] uwsm_hyprland.desktop[1423]: error in client communication (pid 518865)
```

The current session log also shows persistent DRM commit errors on the two-output setup (eDP + HDMI):

```
ERR from aquamarine: drm: Cannot commit when a page-flip is awaiting
ERR from aquamarine: [EGL] Command eglQueryDevicesEXT errored out with EGL_BAD_ALLOC
```

These EGL errors may be related to the GPU context invalidation on resume.

### Coredump analysis (3 occurrences on this machine)

| Date | Mesa version | Signal |
|------|-------------|--------|
| 2026-03-03 | 26.0.1 | SIGABRT |
| 2026-03-27 | 26.0.3 | SIGABRT |
| 2026-05-21 | 26.0.6 | SIGABRT |

All threads waiting in `libgallium.so` at resume — the Mesa GPU context is invalidated by the i915 reinit.

### Suspect stack frames (latest crash)

```
Thread 518874: pthread_cond_clockwait + Hyprgraphics::CAsyncResourceGatherer::asyncAssetSpinLock
Thread 518869: pthread_cond_wait + libgallium (Mesa driver)
Main thread:  pthread_cond_clockwait + hyprlock main loop
```

This strongly suggests hyprlock's GPU-accelerated rendering context does not survive S3 sleep. Hyprlock was launched before suspend (by `before_sleep_cmd`), survived the suspend, but the **i915 DRM context was destroyed and recreated** during resume → hyprlock tries to use stale GPU handles → Mesa aborts.

### Current misc:allow_session_lock_restore state

```
$ hyprctl getoption misc:allow_session_lock_restore
int: 0
set: false
```

`allow_session_lock_restore` is currently **`0` (disabled)** and not set anywhere in `~/.config/hypr/hyprland.conf`. This means that after hyprlock crashes on resume, Hyprland rejects any new lock client trying to re-acquire the session — locking the user out until a TTY recovery.

### Recovery steps that work

```
Ctrl+Alt+F3 → login → hyprctl keyword misc:allow_session_lock_restore 1 && hyprctl dispatch exec hyprlock
```

### Current relevant config

**~/.config/hypr/hypridle.conf:**
```
general {
    lock_cmd = omarchy-system-lock
    before_sleep_cmd = OMARCHY_LOCK_ONLY=true omarchy-system-lock
    after_sleep_cmd = sleep 1 && omarchy-system-wake
    inhibit_sleep = 3
}

listener {
    timeout = 150
    on-timeout = pidof hyprlock || omarchy-launch-screensaver
}

listener {
    timeout = 152
    on-timeout = omarchy-system-lock
    on-resume = omarchy-system-wake
}
```

The `after_sleep_cmd` turns the display on but does **not** verify hyprlock survived the resume.

**~/.config/hypr/hyprlock.conf:**
```
source = ~/.config/omarchy/current/theme/hyprlock.conf

general {
    ignore_empty_input = true
}

background {
    monitor =
    color = $color
    path = ~/.config/omarchy/current/background
    blur_passes = 3
}

animations {
    enabled = false
}

input-field {
    monitor =
    size = 650, 100
    position = 0, 0
    halign = center
    valign = center
    ...
}

auth {
    fingerprint:enabled = false
}
```

### Additional context

- This is **NOT an NVIDIA issue** — this Vostro 7620 has no dGPU (Intel-only)
- The `spd5118` resume error (`-6`) in logs suggests a memory/SPD communication issue on resume, though it may be unrelated
- Confirmed across 3 Mesa versions (`26.0.1`, `26.0.3`, `26.0.6`), so it is not a transient gallium regression
- **Docked environment relevance**: With HDMI always connected, the i915 driver must reinitialize **both** eDP (internal panel) and HDMI outputs on resume. If hyprlock was rendering to the HDMI output before suspend, that GPU context is doubly invalidated on resume. The constant power also means the system enters S3 but AC wake events can race with the lock → wake chain, increasing the likelihood of the stale-context crash.
- **`misc:allow_session_lock_restore`** defaults to `0` (disabled) in Omarchy 3.8.1 and is not set in the shipped `hyprland.conf`. This is a contributing factor — even if hyprlock is killed and re-launched, Hyprland will refuse the new lock session unless this is enabled.

### Related

- #5521 — hyprlock crash while idle on Framework 13
- #3293 — Hyprlock crashes after opening laptop
- https://github.com/hyprwm/Hyprland/discussions/13184 — "Oopsie daisy" session lock state discussion