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