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

[Pekka Paalanen]

On Thu, 6 Nov 2014 05:36:32 +0000
"Zhang, Xiong Y" <xiong.y.zhang at intel.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.
> > 
> 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/