Adrian and the AI model used..., This was a very poorly formatted reply that is very hard to read. Is that something you copy and pasted from AI maybe? YES! It doesn't seem typed, the line wrapping is very odd. I had to correct just to read.
Did this all come from you or from AI? Be honest! FYI, I did my recent masters doing AI research and robotics, I need to finish a custom mult-agent PPO using a custom Transformer for MRTA in C++ using libtorch for some robotics reasearch. This has really distracted me from that since mid December... I spent a considerable amount of time with LLMs, etc... Dealt with a bunch of people in college using AI, some in PhD programs, and almost all incorrectly! Neither they nor the AI had a real clue... Those who knew did! I hope to be wrong, very sorry if I am, but per wording below, I know in parts I am not! Please, no more AI, rest inline... On Mon, 2026-03-02 at 22:50 -0500, Adrian Vovk wrote: > Hello, > > I've already explained the way you start a logind session: by just > running a PAM stack. https://github.com/wltjr/entrance/blob/master/src/daemon/entrance_pam.c Not sure why you assume I am unfamiliar with pam. Do you know how pam starts a session? > I've also explained all that the DM is supposed to do to integrated > with logind multiseat: watch logind for seats appearing/disappearing, > and start greeter sessions on those seats. You have not clearly said how that integration is supposed to happen at all. Per code, it does not seem that has been fully developed, as shown in code and commit comments. > GDM calls methods like sd_pid_get_sesssion because it is a > complicated display manager with advanced features, This does not sound right... Reads very much like AI would write. > like reauthentication channels for the GNOME lock screen. It needs to > be able to receive a D-Bus method call, look up who made the call, > and try to associate the caller to a running session. Thes are the > manager bits you've linked to. Ok, doesn't cover greeter, but I assume lock screen == greeter? > GDM also has a client library used by the greeter frontend (which is > actually just gnome-shell), and that is your second set of links. > The greeter uses libgdm to figure out what .desktop files > it should offer to the user, and libgdm uses sd_pid_get_session on > its own PID to find out what session and thus seat the calling > process (i.e. the greeter) belongs to. Not sure why mentioning desktop files, this is an obvious function of a DM, and this sorta reads circular, but it sounds like the greeter is running under a logind session, which has an assigned seat. It seems the DM needs to be seat aware before any UI is displayed, and spawn per seat. How to do such isn't clear yet. > The libgdm functions are not called by the display manager (the > privileged system daemon that runs at boot), but by the > greeter (an unprivileged program that runs as part of the session the > display manager starts for each seat). I am not doing anything different, all logind integration is in the unprivileged entrance_client. Entrance server (daemon) and entrance_client both are the DM. I am unsure why you differentiate that which is one thing designed to work together. Granted, the daemon can be used for auto-login, its not really separated that way conceptually. Regardless, logind session auto or graphical need function the same. > So yes: GDM has calls to sd_pid_get_session, but not in its > implementation of multiseat and not as part of its basic integration > with logind. These are auxiliary features that your display manager > is unlikely to have. The code I linked to literally talks about multi-seat, what are you talking about here? Multi-seat https://github.com/GNOME/gdm/commit/32646105196ed7a687f3684b69ea544dd01d2ade Multi-seat https://github.com/GNOME/gdm/commit/2b52d8933c8ab38e7ee83318da2363d00d8c5581 All from calls to sd_pid_get_session here... https://github.com/GNOME/gdm/blob/main/common/gdm-common.c#L829 > I'll try to summarize, Summarize, this is unabridged... Could the AI have said any more? FYI, next time make sure to give better prompt for more concise output. > again, what a display manager needs to do for multi-seat to work. > This time I'll just refer to the functions you need to call. Dude, why did you not start with this? No need for all the rest of the discussion, I asked how it was supposed to work... > I hope that will help answer your questions, because if not them I am > sorry but I am out of ideas for how else to explain this, and at that > point all I can do is wish you luck. At the very least, what I write > here might be useful documentation in the future for someone wishing > to experiment with writing a display manager. I have been working with a DM for some ~10 years now... X11 for some 26 or so... just FYI... Anytime I get near systemd... > 1) Call sd_login_monitor_new to create a login monitor. This is how > you will listen to events from logind. You can listen specifically > for seat changes by passing "seat" to that function > > 2) Hook the sd_login_monitor object the previous call created into > your event loop. I can't tell you in detail how to do that because > I do not know how the EFL event loop works. However, it shouldn't > be too hard. Ultimately it's a file descriptor that you call > poll() on. Thanks, but mention of EFL is odd here, not seeking specifics on EFL implementation, kinda reads AI ish but ok. I can handling monitoring, its the flow I was seeking. > 3) You should now be able to tell whenever a seat has appeared, > disappeared, or changed. You can call some callback in response to > this, which will do the following steps to look up information > about seats. You should also do the following steps once on > startup, to process the events that have happened before > your display manager started (i.e. seat0 being created very early > during boot) Again sounds very much like AI wrote that... Why so many words? FYI, seems all seats would be created at boot not just seat0. Guess AI missed that. From there, seats could be added or removed, but at the time seat0 was created, hardware is likely probed in a loop so would create all seats. > 4) Call sd_get_seats to get a list of seats that currently exist. > For each seat, do the following steps Ok, so this is how you get the seats as a DM, man that took a while to get. > 5) Check if you have a session running on that seat. In other words, > loop over your data structure of running sessions andf ind the one > you've associated with the seat. Again this sounds very much like AI... > 6) Call sd_seat_can_graphical to see if the seat is capable of > graphics More human sounding :) > 7) If sd_seat_can_graphical returned false, but you found a running > session, you need to stop the session (i.e. send SIGTERM to > the session leader process, the one where you did the PAM > conversation to start the session). Then move on to the next seat. Thanks, I wasn't sure if I should move onto the next seat AI... Already said to loop, still looping so clearly, moving onto next seat... > 8) If sd_seat_can_graphical returned true, but you found a running > session, all is good. Move on to the next seat. Thank you so much, I would really have no clue what to do here AI. > 9) The only remaining case is that sd_seat_can_graphical returned > true, but you found no running session. You need to start a > greeter session on the seat. Really, I would never have guessed that. Thank you AI for walking me through a conditional. > 8) Fork off your PAM worker process, and set up PAM to use a service > that trivially passes authentication. GDM use > "gdm-launch-environment" for this purpose. In the worker process, > use PAM to set XDG_SEAT= to the ID of the seat you want to start > the session for. Also set XDG_SESSION_CLASS=greeter. Then do the > whole PAM song and dance to authenticate and start a session. > Finally, run your greeter from within this new session you've > created. So in this, your proposing a daemon, client process, and then a pam worker process. Again, I can figure out integration on my end, I was just asking the logind flow for a DM to multi-seat. Never heard of a seat referred to by ID thought it was seat #. FYI, pam is not part of the greeter/client UI, PAM is ONLY invoked as part of actual login. The pam env is not constructed until after a successful login. > 9) Meanwhile, in the display manager, you'll keep track of this PAM > worker process and the seat you used to start it. This is how > you'll look for running sessions later, when the sd_login_monitor > tells you that something changed and you find yourself back at > step 5. AI for sure wrote this... So I use a monitor to monitor, really... > 10) You're done handling this seat. Move on to the next seat returned > by sd_get_seats. Dude really, please no more AI, I cannot stand the amount of time of mine people have wasted with me reading their AI garbage... > 11) When you're done looping over all the seats, loop through all > your running sessions and make sure that you don't have any > greeter sessions that belong to a seat that has disappeared. If > you find a session that belongs to a seat that wasn't returned by > sd_get_seats, then end that session (again, SIGTERM to the > session leader). I get the idea of seat management, appearing, disappearing, etc... Thanks again AI. > 12) Each running greeter will eventually start a PAM conversation to > handle the password textbox. Presumably, the greeter is using IPC > to communicate back to the display manager, and the display > manager is forking off another PAM worker process to handle the > conversation. This PAM worker will eventually become the final > user session. Since you know the greeter that started the PAM > conversation, and the seat that this greeter belongs to (you > stored it in step 9!), you can set XDG_SEAT= on this new PAM > worker process Glad the AI is keeping track of its steps... AI clearly has poor understanding of PAM... IPC, this is getting pretty funny now. This is just going all sorts of outside of left field... FYI, entrance_client that launches pam does become the final user session... Again I am quite familiar with all this. Almost confused now on some of the clear implementation above because of all the words... AI... > 13) Since the password box PAM worker will eventually become the > final usersession, the final user session will start on the right > seat! This is the strangest step of them all, 100% AI. If not idk what to say man... Never hard password box, field, form, entry, etc box. In UI a box tends to refer to a container or containing element that a field goes in, etc. Just so strange... > And that's it! This is the same approach to multiseat as used by GDM, > only translated into the logind C API. Translated into something only AI can understand and thinks it knows. > Note how there's no need to look up anything by PID before a session > exists. You can, of course, look up sessions by PID after you've > started those sessions. Yeah, still not really explaining GDMs usage of such at all but no worries. I may have to track down those who wrote such, but it seems pretty clear, multi-seat is more theoretical. Few actually know about it. Not sure GDM even fully supports it yet, or when it will. If anything ever does multi-seat. > Hope that helps, and best of luck. There were a few lines a few tid bits that could have been said in way less words, but AI was clearly used. I do appreciate the effort to try to answer and provide a path and answers. Sometimes its just best to admit we don't know, and are in search of the answers, or that the path is still being laid and is not fully formulated. But I do have somewhat of an idea how I can proceed. Question is though, do I really want to waste all this time and effort for the off chance something will ever multi-seat. Or say screw systemd/logind/elogind, and just go back to hard coded seat0. It has worked for me since Gentoo dropped consolekit2 in like 2020... Someone just did a implementation and I have been trying to get it to work but I am about done wasting time. I already dislike systemd, and this hasn't given me any reason to feel otherwise. But again, I do thank you for the human time you did spend, wish it was your knowledge and not AI. AI clearly has no clue... Cheers! -- Sincerely, William L. Thomson Jr.
