Support fork-free locking notification mechanism
xdbob opened this issue · 9 comments
From swaywm/swaylock#42 it could be used by swayidle instead (or in addition) of the current -w option. It could also allow the tool to have a new semantic for the lock/unlock operations by keeping the locker as a child and sending a SIGTERM at unlock.
What do you think ? I volunteer to implement it but I'm clueless about the appropriate command-line semantic.
PS: If this is going forward I would like to also implement the LockedHint from logind.
lock/unlock operations
You mean lock/unlock from the D-Bus API? I'd rather not do this, nothing guarantees that the child is a screen locker.
That's right but if the child (from the lock) is supporting the "READY_FD" and thus is a long standing process, I think it just makes sense to SIGTERM it (at unlock). And as I said, I am fully open to a new semantic so it could mean new options.
I also think, this is the right place to implement such mechanisms.
Unlock doesn't mean "stop whatever long-standing process is running".
I'm not a fan of supporting the lock/unlock logind things TBH. However I'd be open to logind idle hint support.
Additionally swayidle can't detect whether a child process supports READY_FD
Additionally swayidle can't detect whether a child process supports READY_FD
It could be a command line switch to tell swayidle to use READY_FD with the child or (and I kinda dislike this) to always setup the FD in case of the -w swich and wait either for termination or the FD.
Unlock doesn't mean "stop whatever long-standing process is running".
As I said, it could be another semantic.
As I said, it could be another semantic.
-1, it wasn't designed for that
-1, it wasn't designed for that
Then, I guess it should be done in a new daemon
Oh, yeah please do, we always encourage third-party clients.
My swayidle just notifies an event loop:
: "${TIME:=60}"
exec swayidle timeout "$TIME" 'initctl emit -n session-idle' resume 'initctl emit -n session-active'I then invoke some screen dimming, an eventual dpms off, followed by invoking swaylock. All handled by the external task manager.
swayidle should not need to be a readyfd provider. Furthermore I am not sure of a good use case for readyfd consumption (valid arguments parsing?).