[systemd-devel] [RFC] VTs for multiple seats

[David Herrmann]

Hi guys

(CC'ing systemd-ML as they proved to be very helpful and interested in this ;))

I am currently working on kmscon and am planning on writing some
user-space VT logic similar to CONFIG_VT in the kernel. The idea is to
have multiple virtual terminals for each seat. systemd-logind
currently associates the kernel VTs tty1-ttyX to seat0 only and all
other seats are not multi-session capable. Moreover, there is no easy
and simple way to make the kernel VTs multi-seat capable. Therefore,
we need another approach.

I was talking to Lennart about this and there is definitely a need to
fix this. However, I have multiple ideas for that and I was wondering
whether you want to comment on this, too, as I saw that one of your
initial proposals for wayland was to have a system wide compositor
which handles all video input and as such would always be active on a
seat (see proposal 3. below).

My ideas:

1) Have a global daemon on some bus (lets say dbus) which opens one
instance of org.freedesktop.vtmaster.seatX. This interface would then
be very similar to the kernel VT interface. That is, clients can
register themselves as a session and deregister themselves again.
Furthermore, apps can request changing the currently active VT and
then the active VT will be notified to release its session and the new
VT will be notified to be active. Additionally, another function would
allow to list all currently available VTs on each seat so we could
have a list where the user could choose one, for example. Advantages:
very similar to in-kernel approach, very powerful API; Disadvantages:
complex API, needlessly keeping the concept of "VT"s, needs global
daemon, needs acknowledgement-roundtrips to avoid drm-master and
input-device races

2) Use a common dbus name for each seat (lets say
org.freedesktop.vtmaster.seatX) and make possible VTs claim this name.
If the name is already claimed, they can put themselves on the
waiting-list (which is a feature of the dbus protocol that is always
available). If a VT is destroyed which was active, the name will
become available and the next client in the waiting-list will
automatically acquire this name and become active. To change a VT, the
active VT simply marks it's name as "loose" (again a dbus feature) and
another client can "take-over" this name which puts the previously
active VT into the waiting-list again. Advantages: no global daemon
(except dbus-daemon, which is available, anyway, though), very simple
API, if carefully designed it's backwards compatible to kernel VTs;
Disadvantages: very limited functionality, VT list cannot be retrieved
by clients, no chance to explicitly change to a VT without a separate
dbus API, very racy in respect to drm-master and input devices

3) Wayland as central VT-master. Let's run a central
wayland-compositor on each seat which acquires the video and input
devices on that seat. This compositor runs all clients in full-screen
mode. An application that wants to open a VT simply creates a new
window on that system wayland-compositor. The compositor implements
some keyboard shortcuts to switch between windows (i.e. VTs).
Advantages: Independent of video/input API, no races on drm-master, no
difference between windows and VTs, direct connection between video
and input devices, bonus points by getting drag-drop support and
similar; Disadvantages: Biggest API of all three approaches (even
stuff like drag'n'drop needs to be implemented by the vtmaster (that
is, compositor)), pulls in a lot of dependencies, needs some separate
API to allow clients to switch to another window (or does
wayland-proto support raising other processes' windows?), limited to
video+input devices (but what about usb-devices, pci devices that are
not video/input devices but still associated with a seat and which
need to be demultiplexed between VTs)

4) Extend kernel-VT API to be seat-capable. I haven't thought about
this very much as I think this is the worst approach of all, but if
someone thinks that this would be a nice way, please speak up ;)
Anyway, Disadvantages: It's in-kernel and increases non-swappable
kernel-memory

I know it's a lot of text but I want to avoid doing this work twice so
I am interested in your opinions. I am in favor of 1) and 3) and would
offer to implement one of them if the majority of us agrees on one
design. I would then report back what my results are and we can
discuss this again ;). If there are no major opinions, I will try idea
3) (wayland compositor).

I am also currently working on patches to make CONFIG_VT go away so we
can get a VT'less system some time from now and I would like to
integrate this with the new vtmaster-idea. If some-one is interested
in any of this work, feel free to join me.

Thanks for your time, regards
David

Btw., I have looked at 1)-2) very carefully and even have API
proposals for them, but I think this would be too much for this email
and I also think most of you are in favor of option 3).