On Thu, 29 Jan 2026 16:45:38 -0500 "William L. Thomson Jr" <[email protected]> wrote:
> For a long time now, I have wanted to have proper integration in > Entrance display manager with logind/elogind. I have read various > freedesktop.org documents and others over the years. While these > questions may seem obvious, I am not asking from an uninformed > perspective. > > > 1. What is the purpose of logind with regard to a display manager, > what is its role and utility? > 2. What is the proper order of integration with logind using the C- > API, not using D-Bus? Hi, what C API would that be? > 3. Should a display manager even be connected to and integrated with > logind, and if so, what should it be doing, what data exchanged? > > > For #1, it seems logind provides means to set some variables such as > SEAT and VTNR, based on DISPLAY, but otherwise, I am unsure of what all > else it is doing and the benefit to integratoin. I would hand-wave that logind is a userspace implementation of the user session concept, as opposed to the archaic kernel virtual terminals (VT). Virtual terminals may exist only on "seat0", but logind supports other seats as well, which are arbitrary collections of input and display (DRM) devices. Logind integrates with the VTs when they exist, so that interoperability with programs using the mysterious VT APIs is maintained. The kernel does not know anything about seats, and eagerly uses all devices for its virtual terminals unless explicitly stopped, which can cause surprises like typing in a GUI text editor going additionally into a shell prompt in a VT. I think logind stops this, but if you used something home-baked, the problem is real. One major purpose of logind is to arbitrate device access for both display (i.e. DRM KMS) and input devices. When you switch between parallel user sessions on a seat, logind make sure that the previous session cannot eavesdrop on the input devices nor mess up the display of the active session by revoking device access, and then granting device access again when the session becomes active once more. I believe a display manager would run in just another user session, as the display-manager-user, with something that allows it to create new user sessions and tell logind to switch to them. libseat might be worthwhile to look at for your display manager's own session: https://git.sr.ht/~kennylevinsen/seatd OTOH, if you need to use logind D-Bus API anyway for managing new sessions, then maybe it doesn't help. For #2 and #3, I can't help, but I have one more comment below. > For #2, it seems pam first, launches a logind session, but you need a > shell session for that, and I need to figure out how to start a > shell/logind, connect to logind session, and then fire the desktop > after in that same shell, which seems like some form of juggling. > > Right now when the desktop is started, maybe incorrectly, logind is > fired off, shell --login, the env is correct, but no means to connect, > as we are trying to connect to logind using a PID that is not > associated to a session yet, and when it has the right PID, we are > waiting for that process to exit. > > We do have a logind monitor, that may have to be its own PID and to be > able to connect to the desktop session PID, that has a active logind > session to connect to. All that seems a bit much, having another > process monitoring, and then what is the benefit of logind? > > > For #3, if logind via pam is setting SEAT and VTNR, it almost seems > like the DM and logind need not even talk to each other or no reason to > integrate with the API, which seems weird, but ok. Trying to understand > what data the DM needs or could use from logind, doesnt seem like > anything is sent, C-API seems read-only, with the rest via D-Bus. > > > I think that covers it, I go over way more in this issue, and welcome > to look at the code. > https://github.com/wltjr/entrance > > entrance_logind_session_get() Failed to get session for PID 418: No > data available > https://github.com/wltjr/entrance/issues/63 > > entrance_logind_session_get() calling sd_pid_get_session() > > Another contributed the logind integration, unfortunately, to correct, > I have had to remove parts. That almost brought me to the question. > > Do I just remove it all; that would be unfortunate but maybe correct? > > What is the point of logind integration with DM and what does each > gain, benefit, and/or need from the other? > > Yes, this can be philosophical in nature, but I am speaking practically > on DM integration with logind. It seems most do not use the C-API, I > assume D-Bus, a direction I was thinking I needed to go before another > did the C-API with logind directly. I also realize, some DMs maybe > going away as they integrate with the desktop because of Wayland. I don't see Wayland changing the fundamentals for display managers per se. I believe display managers used to run their own Xorg instance as some display-manager-user, so that they get X11 to talk to an input/output system. If a display manager moves to be Wayland-based, it still needs something to take the place of Xorg. That could be a "generic" Wayland compositor, or if the display manager is tightly associated with a desktop environment, it will likely run on an instance of the DE's own Wayland compositor. No matter what the display server used by a display manager is, the manager still needs its own session for the display server to access the right input and display devices. Of course, it would be possible to write a display manager running straight on DRM KMS, without Wayland nor X11, but I think the ability to use generic application toolkits like GTK, Qt etc. for the UI is a much bigger benefit. I hope I was able to tell you something new. Thanks, pq > I am not new to any of this, but there is few documentation, its been > the same for years, I have read it, forgot some, never read other, and > looking at source code as well; far from an expert but not really a > novice either. In FOSS always more than one way to do stuff, and not > sure there is any real "correct" way, long as it works, secure, stable, > etc. > > Thanks! >
pgpRWaEwPNo9j.pgp
Description: OpenPGP digital signature
