Pekka, thanks a lot for the detailed explanation. Lets see which way we go.
BR imran On Wed, Nov 5, 2014 at 6:32 PM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Fri, 17 Oct 2014 12:37:37 +0300 > Imran Zaman <imran.za...@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.za...@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"> > >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
