Logind stuff in swayidle could be replaced with systemd-inhibit
emersion opened this issue · 13 comments
Would that work with elogind?
Coolio
Would probably need to have a -d flag to ask swaylock to fork in the background when it's ready. That would be cleaner than the current solution (which is to block inhibition for some time).
Hmm, after looking at this again, it seems that it won't be possible to remove dbus. While systemd-inhibit would work great to inhibit before going to sleep, we still need to listen to the logind sleep event to trigger the command.
Someone suggested listening to the lock event, considering all of this I'd say it's not out of scope for swayidle since it already listens to the sleep event...
I have something written up for listening to the lock event, but it might need a bit more polishing. I think either it should listen for both or neither, but I'm not sure which would be preferred. I think @SirCmpwn had preferred neither (on IRC), but I'm not sure.
Yeah, right now it's inconsistent and the suspend event has nothing to do with the user being idle (even if being idle can trigger suspend). Also, it's possible to configure a systemd service to run swaylock on suspend (https://wiki.archlinux.org/index.php/Power_management#Sleep_hooks). Though, it's not possible to run swaylock on a logind lock event without a dedicated daemon.
As you said, we should choose one strategy and stick to it.
EDIT: it's not that simple for the suspend target: it can't be used in user services:
Note that systemd already have a sleep.target, however, that's a system-level target, and your user-level units can't rely on it.
Yes?
Do you want to (1) remove dbus from swayidle or (2) add lock support? See comments above < 3 days old.
I would lean towards (1) but I don't really care so long as dbus stays optional. I don't use swayidle.
I think it's too late for this.