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). _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
