-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIGUSR1 gets queued up when idle inhibitor is active #51
Comments
Offending code seems to be in this function. Perhaps someone with a better understanding of C can help out? https://github.com/swaywm/swayidle/blob/master/main.c#L852 |
the current behaviour seems to make no sense, but I'm curious as to the thinking behind this @daenney :
personally: I want SIGUSR1 to lock the screen regardless of any inhibitors (as it's coming from me pressing my "lock screen now" hotkey) the current behaviour SIGUSR1 seems completely broken (I suspect it predates the idle inhibitors entirely) |
as a note this happens because the trigger of the timeouts is done by the compositor swayidle asks it to register a timeout 0ms in the future, and when idle is inhibited the compositor doesn't do anything until the inhibition disappears |
Yeah, I agree with that, it would make sense for that to always work. |
It's unclear to me why USR1 shouldn't be handled by just running the timeout commands directly, i.e., why does it go through the compositor and the idle notifications at all? |
OK, I can identify one issue. If we do |
This one's a bit peculiar. When an idle inhibitor is active (I use Waybar's idle_inhibitor module for this, which uses the associated Wayland protocol) sending a SIGUSR1 to swayidle does nothing (this is correct, since the system can't be considered idle). However, the second you turn off the idle inhibitor swayidle believes the system is idle, and thus locks.
I think this is confusing and unexpected, especially since idle inhibition can be active for long periods of time after which your system might surprise lock on you if you forgot you triggered swayidle some way (for example through a lockcmd shortcut in sway).
I would expect that while the idle inhibitor is active, swayidle would discard requests to enter idle state, instead of seemingly delaying processing them.
If I send multiple SIGUSR1's while the idle inhibitor is active you get this instead:
The text was updated successfully, but these errors were encountered: