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

Submitted by Imran Zaman on Oct. 17, 2014, 9:37 a.m.

Details

Message ID 1413538657-3360-1-git-send-email-imran.zaman@gmail.com
State Rejected
Headers show

Not browsing as part of any series.

Commit Message

Imran Zaman Oct. 17, 2014, 9:37 a.m.
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@gmail.com>
---
 protocol/wayland.xml | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

Patch hide | download patch | download mbox

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">

Comments

On Fri, 17 Oct 2014 12:37:37 +0300
Imran Zaman <imran.zaman@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@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">
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@gmail.com> wrote:

> On Fri, 17 Oct 2014 12:37:37 +0300
> Imran Zaman <imran.zaman@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@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">
>
>
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@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@gmail.com>
> wrote:
>
>> On Fri, 17 Oct 2014 12:37:37 +0300
>> Imran Zaman <imran.zaman@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@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
>
>
> 

> On Fri, 17 Oct 2014 12:37:37 +0300

> Imran Zaman <imran.zaman@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@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.

> 

You are absolutely right. But I think wl_seat is equal to physical seat in some conditions and we could use wl_seat as physical seat in our problem. 
Which component will define physical seat ?
We could bind input devices to wl_seat through udev rules and bind outputs to wl_seat through weston.ini, so we could think wl_seat is equal to physical seat if we set all the config file correctly.
This way we could use wl_seat to do resource isolation.
On Thu, 6 Nov 2014 05:36:32 +0000
"Zhang, Xiong Y" <xiong.y.zhang@intel.com> wrote:

> > 
> > On Fri, 17 Oct 2014 12:37:37 +0300
> > Imran Zaman <imran.zaman@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@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.
> > 
> You are absolutely right. But I think wl_seat is equal to physical seat in some conditions and we could use wl_seat as physical seat in our problem. 
> Which component will define physical seat ?
> We could bind input devices to wl_seat through udev rules and bind outputs to wl_seat through weston.ini, so we could think wl_seat is equal to physical seat if we set all the config file correctly.
> This way we could use wl_seat to do resource isolation.

Only if you do not advertise (to clients) wl_seats that do not belong to
the physical seat where the client is running.

Given libwayland-server, that is near-impossible (advertising globals
per-connection) unless you also have a separate wl_display per physical
seat.

Really, on the protocol level, a physical seat is encoded by
advertising only the globals that do belong to that physical seat.

If you add any arbitrary restrictions, like this client must not bind
to that global, you practically break all clients. Doing it more subtly
without raising errors is probably possible, but very ugly. The Wayland
core protocol is simply not designed to be shared across several
physical seats, which means you cannot use wl_seat and wl_output if
your protocol scope is to host multiple physical seats. At least not in
the normal way.

Since you need something more anyway, I suggest you go all the way if
you really need one compositor to manage the displays of several
physical seats: on the system compositor level, do not use wl_seat or
wl_output at all. Invent your own protocol extension (essentially a
shell) that replaces all that in a way, that you can advertise
per-client whatever you need that really belongs to the physical seat.

You likely do not want the system compositor to stand as a middle-man
on the input path. On the output path it is unavoidable, because that
actually is the whole point here. But the input path can be
improved by requesting evdev file descriptors from the system
compositor, so that the session compositors can handle input
themselves. This is also more secure than session compositors directly
opening evdev devices (see systemd-logind integration with input
devices[1]). Or maybe you could get them from systemd-logind directly,
I'm not sure.

The fundamental incompatibility in wl_seat and wl_output is from the
fact that they are globals, and globals are *very* difficult to
advertise per-client.


Thanks,
pq

[1] https://dvdhrm.wordpress.com/tag/logind/