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

Wed Nov 5 11:37:05 PST 2014

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">
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20141105/6c4cd45c/attachment.html>