## What happened

Closing the lid with the session locked intermittently hard-hangs the machine while
it is entering suspend. The screen never comes back and a forced power-off is the
only way out. It happened after 5 of 7 consecutive boots before I worked around it.

The journal of the affected boot ends exactly at the point suspend begins, and never
reaches the kernel's `PM: suspend entry` line, which normally follows within a
millisecond:

```
16:22:13.402  omarchy-shell[1430]:  WARN quickshell.hyprland.ipc: Got removal for monitor "DP-1" which was not previously tracked.
16:22:14.788  systemd-logind[1085]: Lid closed.
16:22:14.789  systemd-logind[1085]: Suspending...
16:22:14.938  systemd-logind[1085]: Lid opened.
16:22:15.073  1password[1496]:      Lock state changed: Locked
16:22:15.087  systemd-sleep[56483]: User sessions remain unfrozen on explicit request
16:22:15.090  systemd-sleep[56483]: Performing sleep operation 'suspend'...
              <end of journal>
```

The following boot confirms it was not a clean shutdown:

```
systemd-fsck[914]:     Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
systemd-journald[680]: File /var/log/journal/.../system.journal corrupted or uncleanly shut down, renaming and replacing.
```

## What I expected

Suspend to complete, or fail and return, rather than wedging the machine.

## Steps to reproduce

Not reliably reproducible on demand. Suspend succeeds most of the time — I have
clean 30-minute s2idle cycles in the same logs. The one failure I captured in full
has two things in flight at once:

1. The lid switch closes and reopens 150 ms apart, after logind has already
   committed to suspending. logind proceeds regardless.
2. A ScreenPad (`DP-1`) display removal 1.4 s earlier, so the display set was
   recently reconfigured.

I cannot prove either is causal. I am reporting it because of the second point
below, which is the part that may be Omarchy's.

## Possible Omarchy angle

`omarchy-system-sleep-lock` runs `sync_clamshell` inside the delay-inhibitor
window, which invokes `omarchy-hyprland-monitor-clamshell` and reconfigures
Hyprland's monitor state on every lid-close suspend. The script's own comment
acknowledges that lid transitions can stall Hyprland IPC. Doing display
reconfiguration in the pre-suspend window on a machine whose s2idle path is
already fragile may be worth a look, even if the underlying hang is a kernel or
firmware problem rather than an Omarchy one.

I would understand this being closed as out of scope.

## Workaround

Forcing S3 instead of s2idle fixes it completely. The firmware advertises S3
(`ACPI: PM: (supports S0 S3 S4 S5)`):

```
# /etc/systemd/sleep.conf.d/10-deep-sleep.conf
[Sleep]
MemorySleepMode=deep
```

Many clean cycles since, with `PM: suspend entry (deep)` and matching
`PM: suspend exit`, and no unclean shutdowns.

## System details

- Omarchy 4.0.0-1, Hyprland 0.56.2, SDDM
- Kernel 7.1.8-arch1-3
- ASUS Zenbook UX8402ZE (Zenbook Pro 14 Duo), firmware UX8402ZE.307 (2023-03-20)
- Intel Core i9-12900H, Alder Lake
- Intel Iris Xe (i915) + NVIDIA RTX 3050 Ti Mobile, nvidia-open-dkms 610.57.04
- Suspend mode before the workaround: `/sys/power/mem_sleep` = `[s2idle] deep`

A redacted `omarchy-debug` log is available on request.