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 used consolekit to start the session, I still haven't a clear > understanding of how/when to start logind. > > https://github.com/wltjr/entrance/commit/03f3d27a871a5563f33c931205f659e728340ee8 You don't. logind is started during boot by systemd. A logind session is started by the `pam_systemd.so` PAM module 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 - 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. 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". 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. 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. At the time, I am still stuck at a chicken and egg, and I am not sure > if there will ever be anything that multi-seats or how that is supposed > to work with the display manager etc. > https://github.com/wltjr/entrance/issues/63#issuecomment-3826950983 > Seems either logind or display manager can set the seat or manage it. > Its fine if that is the case being FOSS, but is there no clear roadmap > here or ideas of how things are supposed to integrate and what to > exchange? > I assumed I needed to use dbus, the person who did the elogind code > used the C-API for systemd, but seems the session isn't handled by > logind, it just is connected to that shell session via PID or > something. > > Just a lot of work and confusion, and per the document logind was > supposed to be trivial and its way more than consolekit was. > Hopefully the above answers a lot of these questions Best, Adrian
