swayidle icon indicating copy to clipboard operation
swayidle copied to clipboard

timeouts are handled in the "wrong" order with SIGUSR1

Open jomority opened this issue 5 years ago • 7 comments

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).

jomority avatar Jan 27 '20 15:01 jomority

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?

emersion avatar Jan 27 '20 15:01 emersion

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

jomority avatar Jan 27 '20 15:01 jomority

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.

maringuu avatar Sep 11 '20 19:09 maringuu

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.

nlbrown2 avatar Feb 08 '21 18:02 nlbrown2

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.

emersion avatar Feb 08 '21 18:02 emersion

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.

nlbrown2 avatar Feb 08 '21 19:02 nlbrown2

Try executing pkill twice:

pkill -USR1 swayidle && pkill -USR1 swayidle

aryklein avatar Jun 03 '22 20:06 aryklein