[PATCH v1] wayland-api: added name/seatname properties to the wl_output

[Pekka Paalanen]

On Fri, 17 Oct 2014 12:37:37 +0300
Imran Zaman <imran.zaman at gmail.com> wrote:

> In a multi-seat configuration, clients may need to filter
> out the outputs based on the (udev) seat it is hooked to or
> based on the name of the output.
> Since version of the output is increased, the change does
> not affect the current implementation and is optional whoever
> wants to use the properties of the output (e.g. its very
> similar that input which has the name property attached to
> it).
> 
> Signed-off-by: Imran Zaman <imran.zaman at gmail.com>

I explained this to you in IRC, and I will document it here again.

The seatname event is the wrong approach to solving the issue, and will
not be accepted. The other event, output name, might be useful though,
but we need to look at it separately and see what use cases it serves.


First, we need to define some concepts.

A physical seat is a set of physical input and output devices. Each
physical seat would have a different person working on it. Every person
has his own monitors, keyboards, mice, etc. Most often, these seats are
completely isolated, in that one person cannot touch another person's
desktop or apps. People like privacy.

Multi-seat means multiple physical seats, which are all served by the
same machine. Implementing the isolation is the major issue here, and
also what I understand is the primary problem you are trying to solve.

Wayland's wl_seat is not a physical seat. It is not a seat at all.
wl_seat is just a collection of input devices (no output devices!).
Several mice under the same wl_seat act as a single pointer. Several
keyboards under the same wl_seat act as a single keyboard.

A physical seat may contain multiple outputs (monitors) and multiple
wl_seats. All these wl_seats will share the same desktop and user. That
desktop expands to all the outputs of the physical seat. Multiple
wl_seats on the same server is not multi-seat, it is more like
multi-pointer and multi-keyboard. You get one pointer per wl_seat, and
one keyboard focus per wl_seat. Each wl_seat may be typing to a
different window at the same time, within the same desktop.

For multi-seat, isolation is best achieved by running one display
server for each physical seat. It is simple and easier to secure.
Unfortunately, it currently also means that you need a separate
graphics device for each physical seat, because we cannot reliably
share the KMS resources of one graphics card.

So, you choose to run a single display server covering all physical
seats, so that you can split the KMS resources of the one graphics
card in the server, rather than in the kernel. Then your major problem
is implementing isolation, and that is what Weston is not written to
support yet.

Your aim must be achieving a similar environment for all applications
and desktop components as what a separate display server instance for
each physical seat would provide.

It makes no sense for the display server to advertise input or output
devices that do not belong to that physical seat. Therefore the
seatname label is useless.

The solution is not to label all input and output devices so that
applications would then pick the ones from correct physical seat. The
solution is to not even advertise unrelated devices at all to the
users' applications.

This is why Weston does not even open input and output devices that are
not intended for the physical seat Weston will be controlling.

That is why adding seatname event to wl_output is completely wrong.

Implementing that isolation in Weston will take a *lot* of effort.


It's probably not feasible to implement the isolation in a single
display server. It would be *so* much easier if each user had his own
session compositor instance. So, we need to make that happen.

You would run one Weston instance as the system compositor, and then
each user (physical seat) would run a session compositor.

This leads to the very problem you are trying to solve here, but we
need to solve it differently. We need a new shell protocol. Maybe the
fullscreen shell could be extended, maybe you need to design a new one
based on it.

The system compositor might not advertise *any* wl_outputs or wl_seats.
Instead, it advertises this new shell interface. Session compositors
use the shell interface to discover the available monitors (not
wl_outputs) on the physical seat, and dedicate one wl_surface for each
monitor. The shell interface would also enumerate the available input
devices, and for example pass opened evdev file descriptors to the
session compositors.

Passing open evdev file descriptors allows the system compositor to
stay in charge of input devices, while stepping off from the input
event path. Session compositors would never go opening evdev devices
themselves, because that would require elevated privileges. Also this
way all the physical seat configurations can be managed in a single
place, with the system compositor.

This should not be too much work to make Weston support running as the
system compositor, but it's still a lot of work.

Also, all session compositors would need to support the new shell
interface.

How would session compositors get assigned to physical seats? You could
have the system compositor (with a login helper application) offer a
login screen, and when a user logs in, the system compositor already
knows which physical seat it is, and launches the session compositor as
the user. This way the system compositor does not need to export any
socket files, because all connections are created beforehand.

I hope that gives you good ideas on how to proceed.

Or, you could choose to pursue developing the KMS resources splitting
in kernel DRM, and then simply use all the existing infrastructure like
any KMS-supporting compositors and systemd-logind to set up your user
sessions like everyone else does when having a graphics card for each
physical seat. It would get rid of the system compositor also from the
output path.


Thanks,
pq

> ---
>  protocol/wayland.xml | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 762482e..7580cdf 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -1741,7 +1741,7 @@
>      </request>
>    </interface>
>  
> -  <interface name="wl_output" version="2">
> +  <interface name="wl_output" version="3">
>      <description summary="compositor output region">
>        An output describes part of the compositor geometry.  The
>        compositor works in the 'compositor coordinate system' and an
> @@ -1879,6 +1879,26 @@
>        </description>
>        <arg name="factor" type="int" summary="scaling factor of output"/>
>      </event>
> +
> +    <!-- Version 3 of additions -->
> +
> +    <event name="name" since="3">
> +      <description summary="name of the output">
> +  In a multiseat configuration this can be used by the client to help
> +  identify the name of the output and consequently the name can be used to
> +  select the output(s) based on the configuration.
> +      </description>
> +      <arg name="name" type="string"/>
> +    </event>
> +
> +    <event name="seatname" since="3">
> +      <description summary="name of the seat the output is constrained to">
> +  In a multiseat configuration this can be used by the client to help
> +  identify the seat which the given output is constrained to and consequently
> +  select the output(s) based on the client own seat.
> +      </description>
> +      <arg name="name" type="string"/>
> +    </event>
>    </interface>
>  
>    <interface name="wl_region" version="1">