EXT: Multiple touchscreen environment with Weston

[Theo BUENO]

On Thu, 2019-06-20 at 12:22 +0300, Pekka Paalanen wrote:
> 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.
Thank you both to you and Ian for the great explanation. I was able to
validate all of that on my test setup, with mainline kernel and drivers
and a DRM  backend.

> 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.
That was my initial confusion here, I thought WL_OUTPUT disappeared
because I could not find any reference in the code after Weston 1.6,
but instead the feature had just been moved to libinput.

Indeed both WL_OUTPUT and WL_SEAT were needed for each touchscreen in
order for my setup to work correctly.

> 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
Yes, unfortunately it is unlikely that open-source drivers with DRM
support will happen anytime soon for my use-case.

Do you have an idea of the amount of work required to make multi-seat
and touchscreen binding work on the fbdev backend ? More generally what
are the plans for this backend in future versions of Weston ? I am well
aware that fbdev is obsolete and should be replaced by DRM but a lot of
legacy hardware will never see that change.

Thanks and best regards,
Théo Bueno.