swaywm/swayidle

timeouts are handled in the "wrong" order with SIGUSR1

jomority opened this issue · 7 comments

jomority commented

When enabling idle state through with SIGUSR1 (pkill -USR1 swayidle), the events are processed in the reversed order than if they are activated through the regular timeout.

Take for example the following configuration:

swayidle -w -d \
    timeout 300 'swaylock-blur -- -f' \
    timeout 600 'swaymsg "output * dpms off"' \
    resume 'swaymsg "output * dpms on"'

Normally, first (after 5min) the screen gets locked by swaylock(-blur), and then (after 10min) the screen gets blanked.
With USR1, these commands are executed in the opposite order: First the screen gets blanked, then it gets locked.
This is a problem in this case, because swaylock-blur needs the display to generate the lock image for swaylock.

Is this behavior intentional?

A workaround would be to use timeout 600 'sh -c \'sleep 3 && swaymsg "output * dpms off"\'&', but this seems to be buggy (the display doesn't turn on anymore).

emersion commented

Is this behavior intentional?

Right now the order is undefined. What would be the "right behaviour"?

  • Execute commands in the order specified on the CLI?
  • Sort by timeout value?
  • Something else?
jomority commented

I would expect it to be sorted by timeout value.
Currently it seems to be the reversed CLI or reversed timeout order.

  • 👍2
maringuu commented

I would also expect them to be sorted by timeout value.
Still I think that sorting by order specified in the config/CLI would be the right approach since it allows custom ordering and does not disallow ordering by timeout value.

nlbrown2 commented

I'd also expect them to be handled by timeout value, the same way they are handled when the computer is left idle. I think it would be (and is) weird that timeouts are handled differently between being idle and SIGUSR1. If desired, I can try to put up a pull request for this, but I'd like to do so only if there is a chance it will be merged.

emersion commented

Maybe it can be as simple as reversing a list insertion order (wl_list_insert inserts at head-of-list, need to add .prev to insert at end-of-list). Explicitly sorting by timeout value will be more involved, not sure we want that extra complexity.

nlbrown2 commented

This would allow for sorting by order in CLI, right? Just want to confirm I understand what you're saying.

Either way, I think having some defined order would be a nice improvement. If sorting by CLI is easiest, then I think that's a fine solution.

aryklein commented

Try executing pkill twice:

pkill -USR1 swayidle && pkill -USR1 swayidle
  • 👍1