Specification for org.freedesktop.DisplayManager DBus API?

[David Herrmann]

Hi

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.

Comments?

Thanks
David