David Heinemeier HanssonandClaude Opus 5
9ddcec272d
Closing the lid could suspend the machine with the session still exposed. omarchy-sleep-lock held a delay inhibitor and waited for Quickshell to report the session secure, but a delay inhibitor is a timer rather than a promise: logind suspends once InhibitDelayMaxSec expires, locked or not. The default is five seconds, and closing the lid also reconfigures displays -- exactly when the lock service is waiting for the screen set to settle before it can secure. The race is now off the critical path. switch:on:Lid Switch runs omarchy-system-lid-close, which requests the lock the moment the lid closes, before logind has decided to suspend at all, so the inhibitor window usually finds the session already secure. A docked lid close does not suspend (HandleLidSwitchDocked defaults to ignore) and must not lock either, since that is clamshell mode still in use on the external display, so the handler gates on the same closed-and-undocked pair logind itself keys on. Suspends that never touch the lid -- idle timeout, the system menu, low battery -- still arrive through the inhibitor, so that path gets room to work too. The shipped drop-in raises InhibitDelayMaxSec to 15s, and the helper derives its budget from logind's live InhibitDelayMaxUSec rather than assuming the drop-in landed: a machine that has not reloaded logind yet, or that carries its own override, gets a budget that fits what logind will actually allow. It leaves logind a fifth of its own window and caps at 12s, so a hand-raised window cannot strand a closed laptop awake in a bag. The wait itself had three defects. Its deadline arithmetic read EPOCHREALTIME assuming a period, so under any comma-decimal locale the subtraction parsed as bash's comma operator and silently voided the deadline, leaving only the attempt counter to stop it. The lock request shared the status polls' timeout and exited on first failure, so a shell 300ms slow meant suspending unlocked; it now has its own budget and is simply retried, since asking again is idempotent. And a refusal the shell reports on stdout with a zero exit -- missing-pam -- read as success, burning the whole window on a lock that could never happen. Every call is bounded by what is left of the budget rather than by an estimate of what the step should cost, so the deadline holds on hardware slower than anything the constants were fitted to. Failure is still possible and it used to be silent. It now writes to the journal and raises a critical notification, which lands on the screen the user unlocks into. Incidentally, monitor-recovery-test asserted lid probing against omarchy-hw-clamshell after that logic moved to omarchy-hw-laptop-closed. It aborted the file under set -e, skipping the nine assertions behind it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
21 lines
848 B
Bash
Executable File
21 lines
848 B
Bash
Executable File
#!/bin/bash
|
|
|
|
# omarchy:summary=Lock and reconcile displays when the laptop lid closes
|
|
# omarchy:group=system
|
|
# omarchy:hidden=true
|
|
|
|
# Locking here rather than waiting for PrepareForSleep is what keeps the lock
|
|
# off the critical path. logind's delay inhibitor is a timer that expires
|
|
# whether or not the session is secure, so starting the lock the moment the lid
|
|
# closes gives Quickshell a head start before logind even decides to suspend.
|
|
# omarchy-system-sleep-lock then usually finds the session already secure.
|
|
#
|
|
# A docked lid close does not suspend (HandleLidSwitchDocked defaults to
|
|
# ignore), so it must not lock either: that is clamshell mode, still in use on
|
|
# the external display.
|
|
if omarchy-hw-laptop-closed && ! omarchy-hw-external-monitors; then
|
|
omarchy-system-lock >/dev/null 2>&1 || true
|
|
fi
|
|
|
|
omarchy-hyprland-monitor-clamshell
|