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

[Lennart Poettering]

On Wed, 04.07.12 20:13, David Herrmann (dh.herrmann at googlemail.com) wrote:

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

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

Yupp, I am also in favour of #3 really. There are so many things that
Wayland offers us that would be useful for us, for example all the input
method/kbd mappings stuff, and some sensible approach to SAK and lock
screens and things. These are really hard to do if you do them without
system compositor or you would have to reimplement a lot of code that
isn't fun.

(Also, I think Plymouth should be replaced by the system compositor as
well, as a side note)

I am strongly of the opinion btw that having a sane terminal directly on
top of the system compositor is highly desirable, for servers and
suchlike.

Given that Wayland is a compositor building kit, I don't understand at
all btw why Weston would be used as basis for this though. This really
sounds as if this should be something much more minimal independent of
Weston...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.