<div dir="ltr">Pekka, thanks a lot for the detailed explanation. Lets see which way we go.<div><br></div><div>BR</div><div>imran</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 5, 2014 at 6:32 PM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 17 Oct 2014 12:37:37 +0300<br>
Imran Zaman <<a href="mailto:imran.zaman@gmail.com">imran.zaman@gmail.com</a>> wrote:<br>
<br>
> In a multi-seat configuration, clients may need to filter<br>
> out the outputs based on the (udev) seat it is hooked to or<br>
> based on the name of the output.<br>
> Since version of the output is increased, the change does<br>
> not affect the current implementation and is optional whoever<br>
> wants to use the properties of the output (e.g. its very<br>
> similar that input which has the name property attached to<br>
> it).<br>
><br>
> Signed-off-by: Imran Zaman <<a href="mailto:imran.zaman@gmail.com">imran.zaman@gmail.com</a>><br>
<br>
</span>I explained this to you in IRC, and I will document it here again.<br>
<br>
The seatname event is the wrong approach to solving the issue, and will<br>
not be accepted. The other event, output name, might be useful though,<br>
but we need to look at it separately and see what use cases it serves.<br>
<br>
<br>
First, we need to define some concepts.<br>
<br>
A physical seat is a set of physical input and output devices. Each<br>
physical seat would have a different person working on it. Every person<br>
has his own monitors, keyboards, mice, etc. Most often, these seats are<br>
completely isolated, in that one person cannot touch another person's<br>
desktop or apps. People like privacy.<br>
<br>
Multi-seat means multiple physical seats, which are all served by the<br>
same machine. Implementing the isolation is the major issue here, and<br>
also what I understand is the primary problem you are trying to solve.<br>
<br>
Wayland's wl_seat is not a physical seat. It is not a seat at all.<br>
wl_seat is just a collection of input devices (no output devices!).<br>
Several mice under the same wl_seat act as a single pointer. Several<br>
keyboards under the same wl_seat act as a single keyboard.<br>
<br>
A physical seat may contain multiple outputs (monitors) and multiple<br>
wl_seats. All these wl_seats will share the same desktop and user. That<br>
desktop expands to all the outputs of the physical seat. Multiple<br>
wl_seats on the same server is not multi-seat, it is more like<br>
multi-pointer and multi-keyboard. You get one pointer per wl_seat, and<br>
one keyboard focus per wl_seat. Each wl_seat may be typing to a<br>
different window at the same time, within the same desktop.<br>
<br>
For multi-seat, isolation is best achieved by running one display<br>
server for each physical seat. It is simple and easier to secure.<br>
Unfortunately, it currently also means that you need a separate<br>
graphics device for each physical seat, because we cannot reliably<br>
share the KMS resources of one graphics card.<br>
<br>
So, you choose to run a single display server covering all physical<br>
seats, so that you can split the KMS resources of the one graphics<br>
card in the server, rather than in the kernel. Then your major problem<br>
is implementing isolation, and that is what Weston is not written to<br>
support yet.<br>
<br>
Your aim must be achieving a similar environment for all applications<br>
and desktop components as what a separate display server instance for<br>
each physical seat would provide.<br>
<br>
It makes no sense for the display server to advertise input or output<br>
devices that do not belong to that physical seat. Therefore the<br>
seatname label is useless.<br>
<br>
The solution is not to label all input and output devices so that<br>
applications would then pick the ones from correct physical seat. The<br>
solution is to not even advertise unrelated devices at all to the<br>
users' applications.<br>
<br>
This is why Weston does not even open input and output devices that are<br>
not intended for the physical seat Weston will be controlling.<br>
<br>
That is why adding seatname event to wl_output is completely wrong.<br>
<br>
Implementing that isolation in Weston will take a *lot* of effort.<br>
<br>
<br>
It's probably not feasible to implement the isolation in a single<br>
display server. It would be *so* much easier if each user had his own<br>
session compositor instance. So, we need to make that happen.<br>
<br>
You would run one Weston instance as the system compositor, and then<br>
each user (physical seat) would run a session compositor.<br>
<br>
This leads to the very problem you are trying to solve here, but we<br>
need to solve it differently. We need a new shell protocol. Maybe the<br>
fullscreen shell could be extended, maybe you need to design a new one<br>
based on it.<br>
<br>
The system compositor might not advertise *any* wl_outputs or wl_seats.<br>
Instead, it advertises this new shell interface. Session compositors<br>
use the shell interface to discover the available monitors (not<br>
wl_outputs) on the physical seat, and dedicate one wl_surface for each<br>
monitor. The shell interface would also enumerate the available input<br>
devices, and for example pass opened evdev file descriptors to the<br>
session compositors.<br>
<br>
Passing open evdev file descriptors allows the system compositor to<br>
stay in charge of input devices, while stepping off from the input<br>
event path. Session compositors would never go opening evdev devices<br>
themselves, because that would require elevated privileges. Also this<br>
way all the physical seat configurations can be managed in a single<br>
place, with the system compositor.<br>
<br>
This should not be too much work to make Weston support running as the<br>
system compositor, but it's still a lot of work.<br>
<br>
Also, all session compositors would need to support the new shell<br>
interface.<br>
<br>
How would session compositors get assigned to physical seats? You could<br>
have the system compositor (with a login helper application) offer a<br>
login screen, and when a user logs in, the system compositor already<br>
knows which physical seat it is, and launches the session compositor as<br>
the user. This way the system compositor does not need to export any<br>
socket files, because all connections are created beforehand.<br>
<br>
I hope that gives you good ideas on how to proceed.<br>
<br>
Or, you could choose to pursue developing the KMS resources splitting<br>
in kernel DRM, and then simply use all the existing infrastructure like<br>
any KMS-supporting compositors and systemd-logind to set up your user<br>
sessions like everyone else does when having a graphics card for each<br>
physical seat. It would get rid of the system compositor also from the<br>
output path.<br>
<br>
<br>
Thanks,<br>
pq<br>
<div class="HOEnZb"><div class="h5"><br>
> ---<br>
>  protocol/wayland.xml | 22 +++++++++++++++++++++-<br>
>  1 file changed, 21 insertions(+), 1 deletion(-)<br>
><br>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml<br>
> index 762482e..7580cdf 100644<br>
> --- a/protocol/wayland.xml<br>
> +++ b/protocol/wayland.xml<br>
> @@ -1741,7 +1741,7 @@<br>
>      </request><br>
>    </interface><br>
><br>
> -  <interface name="wl_output" version="2"><br>
> +  <interface name="wl_output" version="3"><br>
>      <description summary="compositor output region"><br>
>        An output describes part of the compositor geometry.  The<br>
>        compositor works in the 'compositor coordinate system' and an<br>
> @@ -1879,6 +1879,26 @@<br>
>        </description><br>
>        <arg name="factor" type="int" summary="scaling factor of output"/><br>
>      </event><br>
> +<br>
> +    <!-- Version 3 of additions --><br>
> +<br>
> +    <event name="name" since="3"><br>
> +      <description summary="name of the output"><br>
> +  In a multiseat configuration this can be used by the client to help<br>
> +  identify the name of the output and consequently the name can be used to<br>
> +  select the output(s) based on the configuration.<br>
> +      </description><br>
> +      <arg name="name" type="string"/><br>
> +    </event><br>
> +<br>
> +    <event name="seatname" since="3"><br>
> +      <description summary="name of the seat the output is constrained to"><br>
> +  In a multiseat configuration this can be used by the client to help<br>
> +  identify the seat which the given output is constrained to and consequently<br>
> +  select the output(s) based on the client own seat.<br>
> +      </description><br>
> +      <arg name="name" type="string"/><br>
> +    </event><br>
>    </interface><br>
><br>
>    <interface name="wl_region" version="1"><br>
<br>
</div></div></blockquote></div><br></div>