On Thu, 6 Nov 2014 05:36:32 +0000 "Zhang, Xiong Y" <xiong.y.zh...@intel.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. > > > 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/ _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
