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

[Kok, Auke-jan H]

On Thu, Jul 5, 2012 at 3:36 AM, Christopher James Halse Rogers
<christopher.halse.rogers at canonical.com> wrote:
> On Wed, 2012-07-04 at 20:13 +0200, David Herrmann 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.
>
> 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.

I just posted to krh on this topic today as well. This isn't a
specific comment on the topic, but I think it's the right time to open
the discussion.

I'm not so keen on where the systemd logind integration is going in
weston. The logind integration (handling a seat, suspend/resume and
whatnot) are very generic problems, and the problem should probably
get a generic solution.

I've seen 2 projects now create a custom implementation for creating a
pam_session, talk to logind, etc. This hardly makes any sense anymore.

It makes even less sense if you consider implementing a user session.
Underneath the user session wayland/Xorg and applications become just
part of a boxed-in domain that only needs a few hints, and, likely
could even do without entirely at all knowing anything about the vt
number, or display number used.

In any case, weston likely needs to run setuid root, so why would you
implement logind interaction in the same program? That should run as a
wrapper around the systemd user session, not as part of it (although
parts may interact with it).

Weston currently is becoming a swiss army knife, and while it may work
(in one implementation), it's already a giant pain to get weston
running under a systemd user session as non-root, not to mention that
weston pretty much ruins any form of cgroup benefits you get from
systemd due to it also being an application launcher.

I've posted some concerns to Kristian, as I said before. I hope to
turn the design of weston into something that looks like a better
orchestrated group of components that can fully benefit from the
systemd user session than it is right now.

Auke