max / alloy

Lockscreen: single process, multiple lock surfaces (closes #3) ext-session-lock-v1 is per-client by design — one ExtSessionLockV1 object per Wayland client, child surfaces created by the owner. So one-process-per-output isn't an option: it'd require either N renderer processes coordinating with one holder via IPC, or independent processes racing for the lock with only one winner. Single process owns the connection, the runtime, the lock, and N surfaces. One EGL/GL context per surface; all surfaces render from the same snapshot so dot count, error state, and clock appear simultaneously across outputs without coordination. The "isolation if PAM blocks" motivation that originally argued for multi-process is retired: PAM runs on a worker task, the UI thread never blocks, and process isolation buys nothing the task model doesn't already give us. Precedent: swaylock, hyprlock, waylock are all single-process. One open question remains: lockscreen-process crash recovery.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: Max Johnson <me@maxj.phd> · 2026-06-26 19:53 UTC

Signed with PGP, not checked

Commit: 32e960a4c5cf901641b75a5653174e0f2215cda2

Parent: db0eb44

1 file changed, +1 insertion, -1 deletion

M crates/alloy_lockscreen/README.md +1 -1

			@@ -72,7 +72,7 @@
72	72
73	73		1. ~~Wayland protocol crate.~~ Resolved: smithay-client-toolkit. See above.
74	74		2. ~~PAM crate.~~ Resolved: pam-sys + thin in-crate wrapper. See Stack picks above.
75		-	3. Process model. Single-process binding all outputs, or one process per output. Single-process is simpler and matches how swaylock works; one-process-per-output gets us isolation if PAM blocks. Default: single-process.
	75	+	3. ~~Process model.~~ Resolved: single process, multiple lock surfaces. ext-session-lock-v1 is a per-client protocol — the `ExtSessionLockV1` object can only be owned by one Wayland client, and its child `ExtSessionLockSurfaceV1` instances must be created by that owner. One-process-per-output therefore isn't really an option for a lock holder; it'd require either an N-renderer-process IPC dance under one holder, or independent processes racing for the lock (only one can win). Single process owns one Wayland connection, one async runtime, one lock, and N surfaces — one EGL/GL context bound per surface, all surfaces rendering from the same snapshot struct so the dot count, failure state, and clock appear simultaneously on every output without coordination. The "isolation if PAM blocks" motivation that originally argued for per-output processes has been retired by the Resilience contract: PAM runs on a worker task, the UI thread never blocks, so process isolation buys nothing the task model doesn't already give us. Precedent: swaylock, hyprlock, waylock are all single-process.
76	76		4. Recovery path. If the lockscreen process crashes while holding the session lock, the compositor stays locked and the user is stranded. ext-session-lock-v1 has explicit semantics for this; document the chosen recovery path (compositor-side fallback, watchdog, intentional crash-to-greeter) before shipping.
77	77
78	78		## Non-goals as a marquee app