Hi Adrian, Thanks for the reply, also to the other person who replied the other time, I appreciate all trying to figure this out!
On Fri, 2026-02-27 at 17:45 -0500, Adrian Vovk wrote: > Hello William, > > I would suggest that, overall, it may be very helpful to look at the > implementation of an existing display manager for guidance (i.e. GDM, > plasmadm, lightdm, etc). I have been, GDM seems best reference, not exactly clear how others are integrating, but its several functions deep wrapped and they are launching and doing many things differently in GDM. That is my primary reference along with logind code. Another was spawny but I am unsure how accurate that implementation was as its quite old, and I never used it to confirm it worked, proper approach, etc. https://github.com/marcelhollerbach/spawny > You don't. logind is started during boot by systemd. A logind session > is started by the `pam_systemd.so` PAM module Yes, but in my case, this happens when the shell session is created and desktop is launched, and we cannot connect to logind at that point, and maybe it should be D-Bus vs logind via C-API. > So, generally to start a session you just have to: > - Fork off a worker process. This will become the running session. > - Start a PAM conversation in that worker process > - Set some environment variables into the PAM session. See the man > page for > pam_systemd, where it describes the env vars to set. Namely: > XDG_SESSION_TYPE, XDG_SESSION_CLASS, XDG_SEAT, and so on. This lets > logind correctly associate your session with a seat, tell > whether it's X11 or Wayland, tell whether it's a normal user > session or a > greeter, and so on Check, up till this point. The XDG_SEAT is where issue starts. >From what I can tell, either the DM or logind can create the seat. Given the code in logind/elogind for seat creation, I am unsure if that is something the DM should be doing or not. Why have both the DM and logind doing seat management? It was hard coded to "seat0" per freedesktop documentation for sometime, but recently switched to letting logind do that as part of attempted integration, and that seems fine, just no way to detect changes or talk to logind. Setting XDG_SESSION_CLASS to "greeter", we do, not sure the benefit. I am unsure if there will ever be > seat0 though, and how that applies to say VT or other. > - Do the normal PAM authentication and session setup dance > - PAM, as part of its session setup, will talk to logind for you! > - Now that you're inside of the session, run the session leader (i.e. > the > command you find in `Exec=` in the chosen > /usr/share/{wayland-,x}sessions/*.desktop file) > > This is, fundamentally, what you'd already be doing to start a > session on Linux with PAM. Really all you need to do is remove the > consolekit stuff, add the environment variables, and make sure that > `pam_systemd` is present in your PAM stack. Check, logind starts and that session is running, but the DM is not connected to that, DM and logind do not communicate. The DM is waiting for the PID to exit, but no means to connect to logind (same PID), short of forking another process, etc. That is where I am stuck. It seems like the DM needs no logind integration at all. Unless logind and the DM are supposed to communicate, and what that communication should be, which seems to be monitoring seats per below. > The other big change that might need to happen, is that you should > run your greeter session through PAM also. Maybe you're not doing > that, I don't know. You can set up a PAM stack that basically amounts > to "allow login without authentication, and run pam_systemd.so". We are using pam, I was considering making it no longer optional, but it BSD can run without pam, whereas pam is standard on most any Linux distro. BSD may not have logind/elogind either so that is moot. > If you want multi-seat to work, you have to monitor (via DBus) logind > for SeatAdded/SeatRemoved events. Whenever a seat appears, check if > it's graphical (and note that a seat can become graphical later!), > and if it's graphical start a greeter session for it. You can > associate the session to the seat via the `XDG_SEAT` environment > variable, as mentioned above. If you want to get yourself going > without multiseat support, just set `XDG_SEAT` to `seat0`, or > don't set it at all. When that greeter tries to start a session, you > can query its seat, and set `XDG_SEAT` on that new session > accordingly. Ok, this is along the lines of what I am seeking, so the DM is monitoring for seat events, and this is done via D-Bus, though I think you can get R/O events from the logind C-API, assuming we can talk to PID, but seems more like we need to be integrating against D-Bus. I was originally assuming I needed to integrate against D-BUS and not logind via the API as another did, I hate to remove all their logind integration code. Its seems it works for them, but given issues in CI and how it works, I fail to see how. The logind PID is not associated until after we launch session and at that point we are waiting for the PID to exit, no further communication. I am curious to learn more about this seat becoming graphical later, and how another seat shows up. I am curious all around about seats, multi-seat, if a multi-seat system exist, and what that entails. Seems like mainframe stuff, multiple monitors, keyboards, and mice. I have read up on it a lot over the years, some details fail my present memory, I know other devices can be part of all that. Seems also like seat0 uses :0 and also a VT ( VT and :0 maybe same thing, not totally clear on that ) > The final piece of the puzzle is the display server. When it wants to > gain DRM control, or access input devices, or whatnot, it needs to > ask logind (again, via D-Bus). Logind will hand over the resources > that are appropriate for the seat that the given session belongs to > (as determined when the session was created, via the XDG_SEAT > environment variable). Note that what the docs say about the `-seat` > parameter and `systemd-multi-seat-x` is out-of-date, XOrg natively > supports this for you. So do most Wayland > compositors This so far seems fine, recent changes added support for starting Wayland sessions, so both X11 and Wayland can be launched. I believe the main "need" or "issue" around logind and also from consolekit is system actions. If a session is not setup, some desktops won't show like restart/reboot/hibernate, etc system actions. All that has been long working, via pam -> logind and a hard coded seat0. It seems the integration mostly benefits multi-seat and when seats appear etc, which I have yet to observe or know how to even replicate for testing etc. But it seems like its more D-Bus integration and monitoring than logind. If we are not getting what we need from D-Bus wrt to logind, then logind sessoin may not be running yet, then that is where the "greeter" class sessions and others may come in. Right now, short of trying to run the DM under Wayland, I see no point in having the greeter session have anything to do with logind. Its mostly for when the users logs in, and seat aside, making sure system actions are available etc. Unless seats can change and DM needs to spawn greeters on those. > Hopefully the above answers a lot of these question Not conclusively but quite helpful nonetheless, thank you, and more direction than I have gotten otherwise, I do appreciate it, and the prior response from another. It still seems like this is all a WIP, more theory than application, as I would love to see a multi-seat system and how all this is supposed to work, which back to the start, GDM seems best reference, and I guess the primary roadmap for all this. Its FOSS, I know juggling, but if there will never be > seat0, seems like a hard coded is all one would ever need, KISS! Cheers! -- Sincerely, William L. Thomson Jr.
