On Wed, 04.07.12 20:13, David Herrmann ([email protected]) 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
