[RFC] VTs for multiple seats

[Christopher James Halse Rogers]

On Wed, 2012-07-04 at 20:13 +0200, David Herrmann wrote:
> 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 think that the approach should not include VTs at all; they're not
actually very useful for anything we want them to be useful for.

It makes more sense to talk of “user sessions”. We don't *actually* want
to rebuild the existing VT infrastructure in userspace; we want secure
fast user-switching, and secure attention keys that actually work, and
reliable lockscreens. And hey, maybe a fullscreen terminal now and then
for the incurably retro.

These aren't things that are provided by the VT subsystem, except for
the fullscreen terminal; they're things we've kludged on top of it to
some extent.

On a desktop - or, in fact, anything with physical “seat” hardware - the
only thing that VTs are really useful for is debugging when your
graphical subsystem has blown up. We want this to be possible, but it's
distinctly secondary.

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

Robert Ancell (of LightDM fame) and I am in the process of implementing
something very much like this, in two parts: the actual input/output
handled by a system compositor¹ (my side), and the management handled by
the display manager (his side). Display managers already have a concept
of seats and sessions and an API to handle them, and weston has most of
the work for a system compositor done.

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

In this case I'm not sure that what we currently refer to as a VT makes
sense, which makes the rest of this section confusing to me.

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

I'm confused by this - what do you mean by drag and drop support here?
D&D between two VTs, or D&D between two seats?

You can't do either today, and I can't see why you'd want to, so I'm not
sure what you mean here ☺.

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

The actual API required for this is mostly already there in
wayland/weston/xwayland and the existing display managers. This does
require something to address the seat-bound non input/video devices, but
that's essentially just a replacement for ConsoleKit which you already
have and we need to work on ☺.

¹: See https://github.com/RAOF/weston for some in-progress,
totally-will-be-rebased commits.