[systemd-devel] Display manager and logind interaction

[Robert Ancell]

>> For the first point you have a system when two sessions (A and B
>> running on two different VTs) are open.  Session B requests a switch
>> to session A using a fast user switcher UI.  Under the current logind
>> this request would be made to the logind D-Bus service and that would
>> activate VT A via the kernel.  Most current desktops would show a
>> password dialog which would be covering the session to unlock it.  The
>> recommended way of doing this in LightDM (work in progress) is instead
>> to trigger a new greeter running on VT C, perform the authentication
>> there using the same method as a normal login (with associated
>> security benefits) and then unlock session A and switch to VT A once
>> authentication is completed.  For this to work with the current logind
>> I think you would have to do two VT switches or not tell logind which
>> VT sessions A and B are on.
>
> I see the value in a logic like this, but I see serious problems in
> implementing thisi ATM. First of all, what do you do if the user presses
> C-A-Fx to switch to some session x? Do you then immediately forward him
> to the locking VT instead? And the same problem would arise if some user
> code use chvt(1) to switch sessions.

Yes, in this case a locked session needs to blank the display and have
a method for unlocking.  As a stepping stone I'd recommend the
standard lock is still there (e.g. gnome-screensaver in GNOME) but at
some point that should be replaced by the shell showing a black screen
with a button that brings you to the VT with a greeter to unlock (and
says "how did you get here?").  VT switching as it stands really is a
legacy / power feature - there's no way of knowing which VT number to
use when manually switching anyway.

> 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?

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

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.

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.

>> For example if we repeat the two session case now there is the master
>> compositor running on VT1, and both sessions are either not on a VT at
>> all or both on VT1 (depending on how you look at it).  The master
>> compositor needs to know when switching to session A so it can do the
>> appropriate compositor effect between the two offscreen buffers and
>> redirect where input is going.
>
> 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?

>> > I am not sure I understand "switch types". Can you elaborate?
>>
>> The main cases I think are:
>> - Switch to existing session (supported with logind)
>> - Switch to a new session (i.e. showing a greeter to choose user /
>> session type etc) (*)
>
> My assumption here is actually that in a Wayland world the display
> manager never closes his greeter session, and it thus always stays around.

Not necessarily - it can be somewhat dangerous to have a long lived
process lying around that's been accumulating passwords.  Also the
obvious memory cost of a process you are possibly unlikely to see
again.

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