Discussion:
[RFC] VTs for multiple seats
(too old to reply)
David Herrmann
2012-07-04 18:13:14 UTC
Permalink
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).
Christopher James Halse Rogers
2012-07-05 03:36:36 UTC
Permalink
Post by David Herrmann
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.
Post by David Herrmann
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).
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
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.
Post by David Herrmann
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.
Post by David Herrmann
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 ?.
Post by David Herrmann
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.
Alex Deucher
2012-07-05 13:08:04 UTC
Permalink
On Wed, Jul 4, 2012 at 2:13 PM, David Herrmann
Post by David Herrmann
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).
There's also Dave's render node work which has been picked up by Ilija:
http://lists.freedesktop.org/archives/dri-devel/2012-April/021326.html
The basic idea is that you can allocate display resources to separate
drm device nodes and then run separate userspace stacks on top of each
one or submit rendering/compute commands to a render-only node.

Alex
Kristian Høgsberg
2012-07-09 22:17:13 UTC
Permalink
Post by David Herrmann
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
Casey Dahlin
2012-07-10 16:22:13 UTC
Permalink
Post by Kristian Høgsberg
No, wayland is the protocol, weston is the compositor building
toolkit. If you want an EGL compositor on KMS with evdev input, you
But we don't want an EGL compositor. We want bare-bones KMS support.

One of the things he mentioned was replacing plymouth with the system
compositor. Do you really want to pack mesa into the initrd?

The system compositor needs to provide a lightweight SHM-only graphics
stack. It also needs to be able to provide the EGL stack /dynamically/
when the rest of userspace becomes available.

--CJD
Kristian Høgsberg
2012-07-10 18:15:40 UTC
Permalink
Post by Casey Dahlin
Post by Kristian Høgsberg
No, wayland is the protocol, weston is the compositor building
toolkit. If you want an EGL compositor on KMS with evdev input, you
But we don't want an EGL compositor. We want bare-bones KMS support.
One of the things he mentioned was replacing plymouth with the system
compositor. Do you really want to pack mesa into the initrd?
The system compositor needs to provide a lightweight SHM-only graphics
stack. It also needs to be able to provide the EGL stack /dynamically/
when the rest of userspace becomes available.
Yes, so what you want is an EGL/KMS/evdev compositor that can start
out only using sw compositing. How is that *smaller* than weston
again?

Kristian
Casey Dahlin
2012-07-10 18:28:31 UTC
Permalink
Post by Kristian Høgsberg
Post by Casey Dahlin
Post by Kristian Høgsberg
No, wayland is the protocol, weston is the compositor building
toolkit. If you want an EGL compositor on KMS with evdev input, you
But we don't want an EGL compositor. We want bare-bones KMS support.
One of the things he mentioned was replacing plymouth with the system
compositor. Do you really want to pack mesa into the initrd?
The system compositor needs to provide a lightweight SHM-only graphics
stack. It also needs to be able to provide the EGL stack /dynamically/
when the rest of userspace becomes available.
Yes, so what you want is an EGL/KMS/evdev compositor that can start
out only using sw compositing. How is that *smaller* than weston
again?
Good point, I suppose. If you count the module that eventually gets
plugged in to it, it would be a bit bigger.

--CJD
David Herrmann
2012-07-10 19:29:05 UTC
Permalink
Hi Kristian
Post by Kristian Høgsberg
Post by Casey Dahlin
Post by Kristian Høgsberg
No, wayland is the protocol, weston is the compositor building
toolkit. If you want an EGL compositor on KMS with evdev input, you
But we don't want an EGL compositor. We want bare-bones KMS support.
One of the things he mentioned was replacing plymouth with the system
compositor. Do you really want to pack mesa into the initrd?
The system compositor needs to provide a lightweight SHM-only graphics
stack. It also needs to be able to provide the EGL stack /dynamically/
when the rest of userspace becomes available.
Yes, so what you want is an EGL/KMS/evdev compositor that can start
out only using sw compositing. How is that *smaller* than weston
again?
I don't think that is what Lennart has in mind. Or at least I think of
something simpler. Correct me if I am wrong but I thought it is
possible to have a compositor that is only linked with libdrm (and
using only the generic ioctls, no 3D driver dependent stuff). That is,
the clients, whatever they use for rendering, just pass the DRM
framebuffer ID to the system-compositor which simply uses this buffer
as scanout buffer for the connectors. This automatically forces the
compositor to always make clients full-screen as it has no own
buffers. This would be a zero copy mechanism that is as fast as the
client-renderer but doesn't require heavy dependencies in the
system-compositor. Then, if clients are not DRM compatible, the
compositor can still create a dumb-buffer and blit the raw buffers
into the dumb-buffer. This would be a single-copy mechanism but I
think this is even needed when using full EGL/GL stuff but the client
does only pass in shm buffers. Overall, this wouldn't require any
EGL/GL/mesa dependency.
As a fallback, we could even make the compositor use fbdev instead of
dumb-buffers for compatibility reasons (even though I think this is a
bad idea as we probably want to drop fbdev entirely and this is best
achieved by not supporting it).

What we gain by this is a system-compositor that is very simply, very
lean and still very fast. Although, it wouldn't allow any eye-candy
transitions etc.

I don't think this is currently possible with the weston codebase, as
we require each compositor-backend to allow multiple surfaces.

Regards
David
Casey Dahlin
2012-07-10 19:57:24 UTC
Permalink
Post by David Herrmann
I don't think this is currently possible with the weston codebase, as
we require each compositor-backend to allow multiple surfaces.
This part is all the conversation was about.

--CJD
David Herrmann
2012-07-10 20:03:37 UTC
Permalink
Post by Casey Dahlin
Post by David Herrmann
I don't think this is currently possible with the weston codebase, as
we require each compositor-backend to allow multiple surfaces.
This part is all the conversation was about.
Sorry, I meant we require each backend to have multiple _active_
surfaces. This is not needed by the system-compositor as we only need
one active client. As I said all clients are fullscreen so we always
show only a single surface. Or did I miss something?

Regards
David
Casey Dahlin
2012-07-10 21:33:36 UTC
Permalink
Post by David Herrmann
Post by Casey Dahlin
Post by David Herrmann
I don't think this is currently possible with the weston codebase, as
we require each compositor-backend to allow multiple surfaces.
This part is all the conversation was about.
Sorry, I meant we require each backend to have multiple _active_
surfaces. This is not needed by the system-compositor as we only need
one active client. As I said all clients are fullscreen so we always
show only a single surface. Or did I miss something?
That's right. It also might sway the size argument back, as almost all of
weston's window management and a lot of its input code is no longer necessary.

--CJD
Christopher James Halse Rogers
2012-07-11 00:45:16 UTC
Permalink
Post by David Herrmann
Hi Kristian
Post by Kristian Høgsberg
Post by Casey Dahlin
Post by Kristian Høgsberg
No, wayland is the protocol, weston is the compositor building
toolkit. If you want an EGL compositor on KMS with evdev input, you
But we don't want an EGL compositor. We want bare-bones KMS support.
One of the things he mentioned was replacing plymouth with the system
compositor. Do you really want to pack mesa into the initrd?
The system compositor needs to provide a lightweight SHM-only graphics
stack. It also needs to be able to provide the EGL stack /dynamically/
when the rest of userspace becomes available.
Yes, so what you want is an EGL/KMS/evdev compositor that can start
out only using sw compositing. How is that *smaller* than weston
again?
I don't think that is what Lennart has in mind. Or at least I think of
something simpler. Correct me if I am wrong but I thought it is
possible to have a compositor that is only linked with libdrm (and
using only the generic ioctls, no 3D driver dependent stuff). That is,
the clients, whatever they use for rendering, just pass the DRM
framebuffer ID to the system-compositor which simply uses this buffer
as scanout buffer for the connectors. This automatically forces the
compositor to always make clients full-screen as it has no own
buffers. This would be a zero copy mechanism that is as fast as the
client-renderer but doesn't require heavy dependencies in the
system-compositor. Then, if clients are not DRM compatible, the
compositor can still create a dumb-buffer and blit the raw buffers
into the dumb-buffer. This would be a single-copy mechanism but I
think this is even needed when using full EGL/GL stuff but the client
does only pass in shm buffers. Overall, this wouldn't require any
EGL/GL/mesa dependency.
As a fallback, we could even make the compositor use fbdev instead of
dumb-buffers for compatibility reasons (even though I think this is a
bad idea as we probably want to drop fbdev entirely and this is best
achieved by not supporting it).
What we gain by this is a system-compositor that is very simply, very
lean and still very fast. Although, it wouldn't allow any eye-candy
transitions etc.
But I fully expect that some form of eye-candy transitions - and note
that ?eye candy? in this case includes everything down to and including
simple fade-to-black transitions - will be one of the requirements. I
also expect that people will want the system compositor to do more
complicated things, like having an authentication surface for PolicyKit
dialogs.

If you need something in the initramfs (and we do), you can either (a)
scale weston down to a SHM-only compositor which then loads dynamically
loads an EGL backend once userspace is up, or (b) use something like
plymouth's existing KMS framebuffer stuff, and have code in the
system-compositor to seamlessly switch.

But your main system-compositor is going to want to have features that
EGL provides, and it doesn't make much sense to run that compositor on
top of an even more bare-bones compositor underneath.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120711/717c79b5/attachment.pgp>
Continue reading on narkive:
Loading...