More generally, any listener's on-timeout seems to trigger the on-resume of another listener (or at least loginctl does). With the following two listeners (short time for testing purposes):
listener {
timeout = 18
on-timeout = loginctl lock-session # Lock screen when timeout has passed
}
listener {
timeout = 24
on-timeout = hyprctl dispatch dpms off # Screen off when timeout has passed
on-resume = hyprctl dispatch dpms on # Screen on when activity is detected after timeout has fired
}
The intended effect is that after 18 seconds, the lock screen is triggered, and then 6 seconds after that, the screen turns off. However, it seems that the first lock screen on-timeout causes the entire timeout to be reset, and it has to wait another 24 seconds before turning off the screen.
More generally, any listener's on-timeout seems to trigger the on-resume of another listener (or at least loginctl does). With the following two listeners (short time for testing purposes):
The intended effect is that after 18 seconds, the lock screen is triggered, and then 6 seconds after that, the screen turns off. However, it seems that the first lock screen on-timeout causes the entire timeout to be reset, and it has to wait another 24 seconds before turning off the screen.