Closed colemickens closed 1 year ago
Okay, I accidentally had swaylock
without -f
setup for the timeout.
It seems surprising that USR1
triggers the timeout commands, rather than the lock command...
From looking at the code, it seems like USR1 actually schedules new commands for running on idle, and then triggers idle? And I guess those run serialized. So if I'm running swaylock without daemonizing, it's running, waiting, then running it again for the second signal?
Still, if someone can confirm this? And let me know why USR1 triggers all timeouts, rather than the lock
command?
So if I'm running swaylock without daemonizing, it's running, waiting, then running it again for the second signal?
If the -w
flag is passed to swayidle it indeed waits for each command to exit before executing the next. When swaylock is told to daemonize, it only forks when the session successfully locks, so you know that the session is locked before a command that turns off the display or suspend the machine.
And let me know why USR1 triggers all timeouts, rather than the lock command?
lock
commands are run in response to a systemd lock event, where something is trying to lock the user session using systemd/logind interfaces. Same is the case for before-sleep
commands, which are run in response to systemd events about pending system sleep.
Only timeout
and resume
are triggered by sway activity, and SIGUSR1 forces all timers to immediately be considered expired.
Thank you for the explanation @kennylevinsen, and the original thoughts about this on IRC a few weeks ago. I happily now have something that works to auto-lock sway on Yubikey removal, and I now understand swayidle better. Big thanks. :pray:
I have swayidle configured to run
swaylock -f
onlock
.If I run this in zsh, then I have to unlock swaylock twice:
This is surprising, does
swayidle
queue lock events?