Specification for org.freedesktop.DisplayManager DBus API?

Discussion:

Mathieu Parent

2015-03-10 13:45:34 UTC

(Note 1: please CC me)
(Note 2: I have CC-ed two contacts from gnome-shell, one from gdm, one
from lightdm, and the system-logind ML)

Hello,

There are currently several ways to ask the DM to switch to the login screen:
- gdm3 uses org.gnome.DisplayManager.LocalDisplayFactory CreateTransientDisplay
- lightdm uses org.freedesktop.DisplayManager SwitchToGreeter
- old gdm, and kdm seems to use a socket without DBus
- ...

I am not involved in those projects, but I recently needed to switch
to LightDM to have guest sessions, while keeping gnome-shell
([debian-guest-sessions]). gnome-shell send a CreateTransientDisplay
when "Switch user", without any effect.

I proposed a patch to gnome-shell [gnome-shell-SwitchToGreeter], which
currently waiting for an implementation in gdm [gdm-SwitchToGreeter]
and a written specification.

This mail is to start a discussion about this DisplayManager specification.

The current DBus interfaces used by lightDM seems to be a good
starting point [lightDM-API], but some of its API may overlap with
logind.

Also, how can this work in the Wayland world?

What is the way forward to have the same API in all DM?

Refs:
[debian-guest-sessions]:
http://anonscm.debian.org/cgit/users/sathieu/guest-sessions.git/tree/
[gnome-shell-SwitchToGreeter]: https://bugzilla.gnome.org/show_bug.cgi?id=745940
[gdm-SwitchToGreeter]: https://bugzilla.gnome.org/show_bug.cgi?id=745938
[lightDM-API]: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/lightdm/vivid/view/head:/src/lightdm.c#L784

Regards

Mathieu Parent

Mathieu Parent

2015-03-14 11:51:27 UTC

Permalink

Hello,

It seems that Robert's email didn't reach the archives. I'm forwarding it below.

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.
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.
Boolean org.freedesktop.DisplayManager1.CanSwitchToGuest
org.freedesktop.DisplayManager1.SwitchToGreeter(Object Path seat_id)
org.freedesktop.DisplayManager1.SwitchToGuest(Object Path seat_id,
String session-name)
I think we're OK in the Wayland/Mir/post-X world as none of these APIs
should have any detail at this level. We may have issues should
someone want to make a Display Manager with radically different
behaviour but I think that can be resolved should that ever occur.
--Robert

Post by Mathieu Parent
(Note 1: please CC me)
(Note 2: I have CC-ed two contacts from gnome-shell, one from gdm, one
from lightdm, and the system-logind ML)
Hello,
- gdm3 uses org.gnome.DisplayManager.LocalDisplayFactory CreateTransientDisplay
- lightdm uses org.freedesktop.DisplayManager SwitchToGreeter
- old gdm, and kdm seems to use a socket without DBus
- ...
I am not involved in those projects, but I recently needed to switch
to LightDM to have guest sessions, while keeping gnome-shell
([debian-guest-sessions]). gnome-shell send a CreateTransientDisplay
when "Switch user", without any effect.
I proposed a patch to gnome-shell [gnome-shell-SwitchToGreeter], which
currently waiting for an implementation in gdm [gdm-SwitchToGreeter]
and a written specification.
This mail is to start a discussion about this DisplayManager specification.
The current DBus interfaces used by lightDM seems to be a good staring
point [lightDM-API], but some of its API may overlap with logind.
Also, how can this work in the Wayland world?
What is the way forward to have the same API in all DM?
http://anonscm.debian.org/cgit/users/sathieu/guest-sessions.git/tree/
[gnome-shell-SwitchToGreeter]: https://bugzilla.gnome.org/show_bug.cgi?id=745940
[gdm-SwitchToGreeter]: https://bugzilla.gnome.org/show_bug.cgi?id=745938
[lightDM-API]: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/lightdm/vivid/view/head:/src/lightdm.c#L784
Regards
--
Mathieu Parent

David Herrmann

2015-03-15 17:36:07 UTC

Permalink

This post might be inappropriate. Click to display it.

Mathieu Parent

2015-03-15 20:43:28 UTC

Permalink

2015-03-15 18:36 GMT+01:00 David Herrmann <***@gmail.com>:
[...]

Post by David Herrmann
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).
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?

This looks great to me. But how to know if the user wants a terminal
or graphical session?

VT > =7?

Regards

--
Mathieu Parent

David Herrmann

2015-03-16 11:46:19 UTC

Permalink

Post by Mathieu Parent
[...]

This looks great to me.

Good to hear!

Post by Mathieu Parent
But how to know if the user wants a terminal
or graphical session?
VT > =7?

Right now we have a configuration option in logind which reserves VTs
for gettys (I think /etc/systemd/logind.conf ReserveVTs=). This will
obviously always work. However, note that if you disable CONFIG_VT=
and use a console replacement (like systemd-console, kmscon or fbterm)
you will eventually use the same login-manager as a graphical session.
So instead of selecting KDE, GNOME, etc. as session, you simply select
a terminal session and login.

Thanks
David

Robert Ancell

2015-04-14 04:28:16 UTC

Permalink

Post by David Herrmann
Hi

Post by Mathieu Parent
Hello,
It seems that Robert's email didn't reach the archives. I'm forwarding it below.

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).
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