lock-cmd: Configurable accessory process

[kennylevinsen]

The normal swayidle + swaylock setup uses a series of global timeouts to control outputs and locking at once, meaning that timeout behavior for a locked session and an active session are the same.

A user may instead want much shorter, or different, timeouts for the locked session. For example, an active session may have a 300 second timeout to start swaylock, while swaylock has a 30 second timeout to disable outputs.

To easily manage this, lock-cmd allows swaylock to start a process which will be killed with SIGTERM once the session is unlocked, tying the lifetime to the lockscreen itself.

Name open to bikeshedding.

[emersion]

FWIW, I use this trick to achieve this kind of behavior:

swayidle -w \
    timeout 300 'pgrep swaylock || swaymsg "output * dpms off"' \
    timeout 30 'pgrep swaylock && swaymsg "output * dpms off"' \
    resume 'swaymsg "output * dpms on"'

[mstoeckl]

To easily manage this, lock-cmd allows swaylock to start a process which will be killed with SIGTERM once the session is unlocked, tying the lifetime to the lockscreen itself.

Since swaylock exits very shortly after unlocking, I think essentially the same behavior could be obtained using a wrapper script that starts a process, runs swaylock, and when swaylock exits kills the process.

[kennylevinsen]

Yeah, those solutions are probably good enough for upstream swaylock/swayidle.