For future reference, wl_seat is actually more similar to the "MPX" extension for X11, which allows for multiple pointer/keyboard pairs on the same output seat. The only usecases I'm aware of for MPX are display walls and multiplayer game cabinets.
On Wed, Nov 5, 2014 at 11:37 AM, Imran Zaman <imran.za...@gmail.com> wrote: > 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 > > -- Jasper
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
