<div dir="ltr">Pekka, thanks a lot for the detailed explanation. Lets see which way we go.<div> </div><div>BR</div><div>imran</div></div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Nov 5, 2014 at 6:32 PM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 17 Oct 2014 12:37:37 +0300 Imran Zaman <<a href="mailto:imran.zaman@gmail.com">imran.zaman@gmail.com</a>> 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 <<a href="mailto:imran.zaman@gmail.com">imran.zaman@gmail.com</a>> 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 <div class="HOEnZb"><div class="h5"> > --- > 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> > + > +  > + > + <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"> </div></div></blockquote></div> </div>