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

Wed Nov 5 11:48:20 PST 2014

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.zaman at 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 <ppaalanen at gmail.com>
> wrote:
>
>> 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">
>>
>>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>

-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20141105/0622c98f/attachment-0001.html>