[systemd-devel] logind: session management

[Lennart Poettering]

On Wed, 16.05.12 16:01, David Herrmann (dh.herrmann at googlemail.com) wrote:

> Hi

Heya,

> I am currently working on kmscon, a user-space VT replacement. In it's
> current state, it simply runs a console emulator on a VT but in the
> end we want it to fully replace CONFIG_VT. To make it multi-seat
> capable I used sd-login.h and it correctly assigns drm-connectors and
> input devices to all available seats. However, I have several
> questions regarding session management (see below).
> 
> The idea is to have a single process run all the terminals for all
> available seats. We listen for new and going seats and correctly
> reassign available devices. The user can now use chvt to change
> between their xserver, wayland, kmscon or some other VT. That is, if
> kmscon is not active on seat0, we drop drmMaster (and other devices)
> for seat0 and reqacuire them only when the user switches to kmscon
> again. However, all seats are supposed to be independent in respect to
> VT management (we eventually want to drop it entirely)!
> 
> 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). 

No there isn't (yet).

There's only this document:

http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers

which explains a couple of the signals, but is far from comprehensive.

> Should I register a session
> with logind for each terminal that is opened?

Nope, session registration should be done via PAM only. Other code than
pam_systemd should never invoke the session registration bus
functions. That's at least the theory so far.

> 2) How does multi-seat handle VT switches? If two seats are active, I
> guess the xservers share a single VT (lets say vt-7). If one user
> performs a "chvt 1", does that switch to vt-1 for all users? In other
> words, if one user switches to kmscon, then all users are switched to
> kmscon as kmscon and an xserver cannot technically run on the same VT,
> right?

Right now kernel VT switches are only available on seat0. The X servers
run on that seat have one VT each. seats running on other seats have no
VT assigned at all.

The shell command "chvt" only acts on seat0.

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

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.

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

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

Hope this is useful. The summary I guess is that all of this is still
very much in flux.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.