3 ms·
I have no idea about some of those other desktops, but all the basic moving parts are mostly necessary: - logind because you probably still want lid/sleep even
by md8z 5y ago
I have no idea about some of those other desktops, but all the basic moving parts are mostly necessary:
- logind because you probably still want lid/sleep events to work when at a VT
- gdm because you probably still want lid/sleep events to work while nobody is logged in
- desktop settings because different users may want different things to happen on those events
I'm a little confused as to why the gdm settings were needed, at least for me those only take effect when the greeter is actually open. And in GNOME the separate screensaver daemon has been removed, in part because it simplifies the whole equation.
- kelnos 5y agoIt's been a long time since I've worked with this stuff in any depth, but I wonder if there's the concept of "handoff". While a VT is front-and-center, logind should be in control. While GDM is in the foreground, GDM should be in control. While the desktop environment... etc. But it seems to me that each of these things aren't entirely aware of the other, and constantly fight for control. I know logind has an "inhibit" API that lets another program take over some functions, but who knows if everyone uses it properly. And does GDM have the same thing? Or is it expected to just know when it should step aside?
- md8z 5y agoYes, part of it is the inhibitor API although IIRC there are some other parts. GDM and GNOME share the same implementation of this API so they should at least do the right thing, not sure about other desktops and login managers. Edit: The other part is the device handling logic in logind: https://www.freedesktop.org/software/systemd/man/org.freedesktop.login1.html#Signals3 https://www.freedesktop.org/software/systemd/man/org.freedes... Older tools which may use suid helpers to open these devices will probably stomp all over the logind handling.