Hi On Sat, Mar 14, 2015 at 12:51 PM, Mathieu Parent <[email protected]> wrote: > Hello, > > It seems that Robert's email didn't reach the archives. I'm forwarding it > below. > > 2015-03-12 5:13 GMT+01:00 Robert Ancell <[email protected]>: >> Note I have removed the systemd-devel list from this so we're not >> cross-posting. I think the XDG list is the right place to discuss this >> though of course the input of the systemd developers would be very >> useful. >> >> As the LightDM maintainer I support any moves to get a common API across DMs. >> >> As pointed out, logind has an effective API that has some duplication >> with the current org.freedesktop.DisplayManager API. So I think if we >> want to make a common API we should simplify what we currently have. >> In particular I'd drop the Session / Seat object in >> org.freedesktop.DisplayManager and rely on using the >> org.freedesktop.login1 versions instead. For systems that don't use >> logind you would be limited to single seat for the display manager. >> >> The main cases that I have seen which aren't currently provided by logind >> are: >> 1. Switching to the login screen to choose a new session >> 2. Switching to a guest / temporary account >> >> I think 1. has to be performed by the Display Manager since logind has >> no method of forwarding that request easily unless it gains the >> concept of a special "greeter" session. >> 2. would be nice if it was handled by logind but this would take quite >> some work.
Our plan with logind is to avoid any display-manager API. Instead, we kinda want this to be 'session-activated'. That means, by using the SwitchTo() API in logind, you can activate *any* VT (or using chvt, in case CONFIG_VT=y). You can now configure service symlinks which are activated by logind if a given VT position is activated and no session is running on it. Therefore, a simply VT-switch to an empty session will spawn your login-manager. Once the login manager is done, the session can take over the same VT (or spawn on a new one, it's up to the login-manager to decide). This is basically what we already do with [email protected] to spawn gettys on demand. This allows us to avoid running a login-manager on a fixed VT. Instead, the user simply selects the VT where it wants to login and the login-manager is spawned there. Imo, this feels more natural, instead of having to 'know' where the login-manager is running and switching to that VT. Furthermore, you now have control on which VT your session is spawned, instead of a random VT. Once kdbus is done, I intend to go ahead and implement those ideas. We've been talking about this for way to long without any code showing up. Sorry for that. Comments? Thanks David _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
