[systemd-devel] logind: session management

[David Herrmann]

Hi Lennart

On Mon, May 21, 2012 at 10:18 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Wed, 16.05.12 16:01, David Herrmann (dh.herrmann at googlemail.com) wrote:
[..snip..]
>> 3) The idea behind kmscon is to set CONFIG_VT=n (for several different
>> reasons but mainly to avoid having UI code in the kernel). Does
>> systemd provide a simple way to replace the VT-switching logic? My
>> idea was using sd_login_monitor to watch for session changes. If it
>> changes, I check with sd_session_is_active() whether my session is
>> still active. If not, I stop using the drm, input, etc. devices and
>> for instance an xserver can show up. If the user switches to kmscon
>> again, I am notified via the sd_login_monitor and
>> sd_session_is_active() will be true again and I can start showing up
>> again. The interface for switching "VTs"/sessions would then be some
>> kind of "sd_activate_session" dbus/library call.
>> However, looking at logind sources it seems the "active" logic is
>> tightly bound to VTs. I would start working on implementing this,
>> however, I'd like to get some review on the idea before I spend too
>> much time in it.
>
> It shouldn't be too hard to beef this up in logind. So far indeed only
> kernel VTs are supported.
>
> I expect that doing the VT switching fully async won't be too much fun.
>
> If you implement VTs in userspace I'd avoid all the complexity of kernel
> VTs with the preallocated VTs and fixed device mappings.
>
> Honstely I am not entirely sure how virtualized VTs should exactly
> work. I have one suspicion though: if we do this we probably should do
> this based on a Wayland system compositor. The wayland folks are
> planning to have one anyway, and it should probable be the code that
> does VT switching. Also, there's a good chance that a minimal wayland
> compositor for systems without opengl is doable.

There is a software OpenGL/EGL backend based on fbdev. It is pretty
easy to make wayland use it. There is even ongoing work to make
wayland work without the mesa GL stack and use pixmap etc. for the
compositing.

Anyway, I'd like to see vt-switching independent of wayland.
Otherwise, you couldn't run x11+kmscon without wayland (or any other
combination).

> So I am not entirely sure what to suggest here: a) implement hooks
> in logind specifically for kmscon to emulate VTs; b) do the same, but
> for a plymouth compositor; c) allow this to be abstract and allow two
> implementations.

Plymouth? I think you mean wayland? Plymouth is independent of seats I
think. Anyway, I'd prefer c).

> I am generally not too much of a fan of keeping things too abstract, but
> maybe in this case the iface could just be kept abstract by side-effect.
>
> We could implement VT switching via D-Bus iface. i.e. if a certain bus
> name exists we use its functionality to do VT switching instead of the
> kernel interfaces. This bus interface would have to provide:
>
> - Notification about VT switches
> - Call to trigger a VT switch
> - Call to allocate a VT
> - Call to disallocate a VT

Yes. My idea was something like "org.freedesktop.vtmaster" with an
interface that does:
 - Return a list of names for registered VTs
 - Return the currently active VT
 - Function to request to activate a specific VT
 - Function to register/unregister a VT
 - Signals about VT switches

Each VT then has to implement:
 - listening for signals so the VT sees when it becomes active
 - an interface with a function that is called if the VT should become
inactive. If the function fails, then the VT switch will fail, too. So
a VT can reject being put in background.

The daemon which implements that can be integrated into other daemons
like wayland, logind or kmscon or rather be independent.

If it is independent it could also provide a generic way to switch
VTs. That is, listening on input devices in the background and waiting
for ctrl+fX to change VTs.

I will try it out and send my results to this list again. And I will
talk to Kristian and the wayland guys about it so we can all agree on
a system that works best for all.

>> 4) Does systemd implement some internal timeouts for device
>> reassignments? Imagine drm-card0 is assigned to seat5 and the user
>> reassigns it to seat6. If the xserver starts directly up on seat6, it
>> might not be able to get drmMaster for the card (xserver crashes in
>> this case) because the process on seat5 did not release the drmMaster
>> fast enough. The VT-switching logic uses roundtrips to acknowledge
>> release/acquire, however, I cannot see something like this for logind
>> session/device switching.
>
> The correct fix to this problem appears to be a revoke() system cal as
> it has been discussed many times. Without that the best way is probably
> to patch the clients in question to use inotify to watch when the device
> is closed. THis is what PA does. Some devices OTOH may be opened
> multiple times (input...), so for them the problem might not exist.

Yes, without revoke this gets pretty hard. But it seems this problem
is known so I don't need to worry too much about it now.

On Mon, May 21, 2012 at 10:22 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Sat, 19.05.12 14:55, David Herrmann (dh.herrmann at googlemail.com) wrote:
[..snip..]
>> > 1) Is there any documentation of the logind DBus API? When kmscon is
>> > started on a seat, the user can open multiple terminals (similar to
>> > tabbed windows in terminal emulators). Should I register a session
>> > with logind for each terminal that is opened?
>>
>> There seems to be no documentation. However, as far as I can see I
>> should register a single session for kmscon regardless how many
>> terminals the user opens. The whole kmscon application is then
>> considered one session.
>
> The getty should register the session, not kmscon. (I assume that kmscon
> does not actually do any authentication on its own, does it?)

Exactly. Kmscon opens a pty and passes that to a client which then
does authentication (probably via pam). Just like the x11 terminal
emulators do. So I do not need to worry about that. That's nice.

Thanks
David