[systemd-devel] Display manager and logind interaction

[Lennart Poettering]

On Wed, 15.02.12 19:42, Robert Ancell (robert.ancell at gmail.com) wrote:

> > And on seats != "seat0" we currently don't have any kind of session
> > multiplexing. Hence having a special VT for lock screens is really hard
> > to do... (I have actually discussed this topic with the Wayland guys at
> > FOSDEM and we'll probably have userspace VT switching based on Wayland
> > one day, but that's work for the future).
> 
> Interesting; they are still considering the concepts of VTs still
> applicable?

Well, "userspace VT switching" only means the rough idea of allowing
multiple concurrent sessions on the same seat. Presumably it won't
resemble too closely the current VT switching implemented in the Linux
kernel, and the assignments of F1-F12 will probably be virtualized.

> > I am tempted to say that until the moment we do VT switching in
> > userspace with Wayland implementing proper lock screens is really hard,
> > and probably not worth the effort.
> 
> I hope we can work out something now, as this will come up in the
> future and if the API doesn't support it things are going to get
> messy.

I think the current design is good enough so that we can rework this
later without breaking too much compat.

> One option is to stop logind making the ioctl calls and leaving that
> to the DM.  Then we'd have an API that would work if you wanted to use
> a non-VT based solution.

Well, I have no problem at all in replacing the ioctl based
impelemntation by something else if the time comes.

> The session switching really is quite similar to the X problem of
> having an external component in charge of something that only the
> compositor (the DM in this case) can do reliably.  Another option is
> to not have logind do any switching at all. The only value I can see
> in CK/logind being in control of switching is it allows multiple DMs
> to be run and text consoles to be mixed with graphical ones.  Both of
> these don't seem like important cases to support.

Dunno, I think it is quite an important method on a session the way
logind keeps track of it to activate it. How that is implemented
however, is an implementation detail, and we can replace that easily if
the time comes.

> > Well, with Wayland the entire notion of kernel VTs would go
> > away. Instead, the system compositor could simply redirect VT numbers to
> > different sessions dynamically.
> 
> Then why keep the concept of VTs at all?

multi-session is a useful feature, and we want to keep it. Of course in
this future world there would be not /dev/tty7 devices, as that is only
inherent to the kernel-based VT logic.

> >> - Switch to a new session for a KDE session for user X (not
> >> particularly likely but a case may come up requiring settings some
> >> session choices)
> >
> > We explicitly want to forbid multiple local graphical sessions by the
> > same user in systemd.
> 
> Here I mean something like SwitchToUserWithParameters.  i.e. you may
> want the KDE user switcher to switch to 'lennart' with a KDE session
> but the GNOME Shell one to switch to 'lennart' with a GNOME session.
> Not a major case though.

Well, when I say multiple local graphical sessions I mean just that, and
have no plans to distuingish between GNOME and KDE in that.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.