Skip to content
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

Drop logind integration #117

Open
emersion opened this issue Jan 18, 2022 · 12 comments
Open

Drop logind integration #117

emersion opened this issue Jan 18, 2022 · 12 comments

Comments

@emersion
Copy link
Member

It's hard to maintain, it's the source of many bugs, and it duplicates functionality with Wayland-native interfaces which provide the same functionality.

@bowmanjd
Copy link

bowmanjd commented Mar 3, 2022

Curious what this would mean... Would everything enabled by HAVE_SYSTEMD no longer exist?

@kennylevinsen
Copy link
Member

Curious what this would mean... Would everything enabled by HAVE_SYSTEMD no longer exist?

Yes, HAVE_SYSTEMD and HAVE_ELOGIND.

@bowmanjd
Copy link

bowmanjd commented Mar 6, 2022

Yes, HAVE_SYSTEMD and HAVE_ELOGIND.

Thank you. Just considering what features will not be sticking around. I am assuming lock, unlock, and idlehint would go away.

I am less certain how to handle locking the screen after, say, laptop lid close, if I am right that before-sleep would be removed. I guess this could be left entirely to systemd, though. If this is possible using "Wayland-native interfaces", then I am eager to see what documentation updates would accompany this change.

Thanks for all the work you all are doing on this project. Such a useful tool!

@kennylevinsen
Copy link
Member

before-sleep only has value when you are trying to have both sway/swayidle and logind handle idle actions like suspending.

Just remove the actions from /etc/systemd/logind.conf and use swayidle and sway bindsym/bindswitch to trigger suspend.

For idle actions, there is no point in having sway tell swayidle, which the tells logind, which then runs actions when swayidle is meant to run them directly. For button actions, it makes no sense to have logind waste resources by eavesdropping in all input devices when sway bindsyms can do the trick. For direct loginctl suspend calls, just start swaylock first.

@dkwo
Copy link

dkwo commented Mar 16, 2022

Would this allow swayidle to work even without dbus?
Currently, at least on void linux, I get errors and swayidle does not work if dbus is not present.

@emersion
Copy link
Member Author

swayidle can already work without dbus if you compile it with logind support disabled.

@dkwo
Copy link

dkwo commented Mar 16, 2022 via email

@LinArcX
Copy link

LinArcX commented Aug 17, 2022

What are the alternatives guys?

I have void Linux and I can't use swayidle functionalities like before-sleep.

@kennylevinsen
Copy link
Member

  1. We have not removed it yet, so before-sleep still works.
  2. The alternative to before-sleep is just not using it and calling whatever you need to run before suspend - you'll never guess it -before you call suspend.

@nyonson
Copy link

nyonson commented Aug 17, 2022

Not a Void linux alternative because still systemd-based, but I think systemd-lock-handler could replace before-sleep if one wishes to still use logind events for whatever reason, but not have to do the work of getting them to user (instead of system) space.

@boucman
Copy link
Contributor

boucman commented Aug 17, 2022

hmm, when swayidle tells logind that the system is idle, IIUC logind will lock all the sessions (for the lock action) of all users.

it's a bit more complicated than that, but i'm not sure swayidle alone can reproduce that feature...

inherently, locking, hibernating etc is a system action, so logind is the passage from user demands to system actions and i'm not sure how to properly work around that.

ItsDrike added a commit to ItsDrike/dotfiles that referenced this issue Nov 20, 2022
Swayidle will likely end up dropping logind support, and they themselves
describe it as unstable. For this reason, move to the suggested
alternative: systemd-lock-handler, and just have swayidle run the
command to trigger the logind session lock event, picked up by
systemd-lock-handler.

See <swaywm/swayidle#117> for reference.
@eternal-sorrow
Copy link

So there will be no support for lock? That's too bad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

8 participants