Specification for org.freedesktop.DisplayManager DBus API?

David Herrmann dh.herrmann at gmail.com
Sun Mar 15 10:36:07 PDT 2015


On Sat, Mar 14, 2015 at 12:51 PM, Mathieu Parent <math.parent at gmail.com> 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 <robert.ancell at canonical.com>:
>> 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 autovt at .service 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.



More information about the xdg mailing list