EXT: Multiple touchscreen environment with Weston

[Pekka Paalanen]

On Thu, 20 Jun 2019 05:19:09 +0000
"Ray, Ian (GE Healthcare)" <ian.ray at ge.com> wrote:

> > On 17 Jun 2019, at 17.45, Theo BUENO <theo.bueno at actia.fr> wrote:
> > 
> > Hello everyone,
> > 
> > I am (relatively) new Weston user working with industrial embedded
> > Linux systems. I am seeking for advice regarding a Weston use case.
> > 
> > I have been trying to understand how would one map touchscreens to
> > unique displays on a system which has several touchscreen displays.
> > It is my understanding that prior to Weston 1.7, it could be done
> > via the WL_OUTPUT udev variable for each touchscreen. 
> 
> We are using Weston 6 with libinput 1-13.0 and we use WL_OUTPUT for
> this purpose.
> 
> Sample log output:
> 
> Jun 19 14:17:48 GE0040973102BC weston[305]: [14:17:48.764] event1  -
> DIALOGUE INC PenMount USB: is tagged by udev as: Touchscreen Jun 19
> 14:17:48 GE0040973102BC weston[305]: [14:17:48.765] event1  -
> DIALOGUE INC PenMount USB: device is a touch device : Jun 19 14:17:48
> GE0040973102BC weston[305]: [14:17:48.913] associating input device
> event1 with output LVDS-1 (LVDS-1 by
> udev)                               
> 
> And UDEV rule:
> 
> SUBSYSTEM=="input", KERNEL=="event[0-9]*",
> ATTRS{modalias}=="usb:v14E1p6000*", … , ENV{WL_OUTPUT}="LVDS-1"
> 
> 
> > Now with more recent versions of Weston, by reading through
> > documentation and code, it is also my understanding that such a use
> > case is addressed via logical seats (WL_SEAT) or through physical
> > seats (ID_SEATS) on a multi-compositor/GPU design.
> > 
> > Problem is, on the embedded platform I am working on (NXP i.MX6),
> > there can only be one compositor instance bound to the GPU driving
> > multiple displays. With DRM support, I believe assigning a "seat"
> > option to each "output" entry in weston configuration is enough to
> > constrain each touchscreen to their respective displays.
> > Unfortunately, on i.MX6 there is no DRM support with proprietary
> > drivers. The only available backend is fbdev, which after code
> > review does not seem to allow for multiple seat configuration on
> > the same weston instance.
> > 
> > Am I correct to assume that my only option from here is either to:
> > 1) Bring multi-seat support to fbdev backend
> > 2) Move to free drivers with DRM support
> > 
> > Have I missed something / Are my assumptions correct ?

Hi,

Ian already provided you the solution, but I want to explain a little
more.

Physical seats will have a separate compositor instance running for
each. This means each physical seat may have a different user
logged in, doing their very own work securely isolated from the other
physical seats. Since DRM devices cannot the "split" at the kernel UAPI
level, you will need one DRM device for each physical seat. Physical
seats are intended to give the feeling of using completely separate
machines.

Inside one physical seat, you can have one or more logical seats. A
logical seat means more or less a set of input devices that belong
together and share the same keyboard focus, pointer cursor, and
touches. Logical seats do not really concern outputs, because one can
(at least in the current implementation) simply move e.g. pointer from
one output to another. If you have two logical seats, you may have two
independent pointers on screen, each acting independently on the same
application windows.

If you want to have a single physical seat with multiple touchscreens,
you do what Ian explained. If you wanted each touchscreen to be a part
of a different physical seat, then you'd use ID_SEAT to tag them
accordingly. If any physical seat may have more than one output, then
you really should set WL_OUTPUT to ensure the touch input gets mapped
correctly.

If you wanted each touchscreen to be independent from each other but
still part of the same physical seat, you would tag them with WL_SEAT.
I think Weston does not handle setting outputs of a DRM device to
different WL_SEATs, so you still need the WL_OUTPUT property on the
touch devices to associate them with the right output.

When you have two touchscreens in the same logical seat, and you have
one finger down on one touchscreen and another finger down on another
touchscreen, it will count as if you had two fingers down on one big
touchscreen.

When you have two touchscreens in different logical seats, and you have
one finger down on one touchscreen and another finger down on another
touchscreen, it will count as two separate touchscreens with one
(independent) finger down on each.

I hope this clarifies the different configuration possibilities, and
lets you pick the most appropriate one for your use cases.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190620/d81e5a87/attachment.sig>