Specification for org.freedesktop.DisplayManager DBus API?

[Robert Ancell]

On Mon, Mar 16, 2015 at 6:36 AM, David Herrmann <dh.herrmann at gmail.com> wrote:
> 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?

The important part of the display manager API is not just to start new
login screens but to pass some information about what that screen
should show.

Some examples:

You are logged in as "david" and you want to switch to "robert". So if
we tell logind we need a new VT for this session we want the greeter
that is run on that session to have "robert" pre-selected. And in the
case that "robert" doesn't require a password we want to skip the
login screen entirely and just start the session.

You want to run a temporary guest session. We need to tell logind that
the session spawned should be a temporary guest session.

You use a greeter a lock screen (for security / consistency purposes
instead of running a lock inside the user session). We need to tell
logind that the greeter should be run as lock mode with the current
user selected.

You want to switch to a more exotic session type like a RDP session.
We need to tell logind which session to use.

These are all cases that LightDM currently supports and it would be
good if the logind API could handle things like this. Because there
are many different cases (and likely to be more in the future) I think
we need some sort of generic hint system in the SwitchTo() method that
can be passed to the display manager that starts there. It's probably
safe to just revert to a standard greeter if the hints are not
supported.

I think if we can get that hint information to what is run on the VT
then we should be able to use the logind API for these use cases.

The other challenge is what we do in a post VT world. In Ubuntu we are
using a system compositor to transition between sessions. This allows
us to implement the complex transitions we want but it is currently
controlled within LightDM. I think this problem is probably orthogonal
to the new session problem but also worth thinking about.

--Robert