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

[Kristian Høgsberg]

On Mon, Jul 09, 2012 at 10:27:35PM +0200, Lennart Poettering wrote:
> 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...

No, wayland is the protocol, weston is the compositor building
toolkit.  If you want an EGL compositor on KMS with evdev input, you
don't get much more minimal than weston.  Don't let the toy-desktop ui
fool you, that's a demo and wouldn't be part of a system compositor.
You can argue that weston is too minimal for a full desktop and that
we should use mutter or kwin etc for that.  But I honestly don't know
what you have in mind when you say you want to go smaller than weston.

Kristian