Dual-head kiosk/embedded application

[Nicolas Jeker]

Hi All,

I'm currently working on a solution to run two instances of a full
screen application on separate screens with separate touch screen
input. This is pretty easy if the application has Wayland support by
using a pair of wl_seats, one for each output and touch screen. Multi-
seat with X11 on a single graphics card is as far as I understand
impossible.

Unfortunately, the application in question is written in WinForms and
is running through mono, which only has an X11 backend on Linux.
There's XWayland as a bridge to Wayland, but a mechanism for input
separation seems to be inexistent. I stumbled upon cage [1] in a
discussion from July on this list, but that has neither multiple output
support nor input separation.

So I implemented a very rough Wayland backend for WinForms on mono as a
first POC, which works surprisingly well. It's software-only (wl_shm)
and abuses subsurfaces for widgets. So far I'm using weston as the
compositor.

The long-term solution to this problem will be a rewrite of the
application with another GUI toolkit. I have three possible mid-term
solutions in mind, but I am unsure about how I should proceed and which
approach is the most reasonable.

Solution a) is continuing to develop a Wayland backend for mono. This
would mean implementing proper buffer handling on the client side
instead of abusing subsurfaces. There was a discussion about client
side buffer management on this mailing list in June. My conclusion is
that it's possible, but not an easy task judged from my experience with
the X-centric backend abstraction in mono.

Solution b) is trying to extend XWayland to support separate wl_seats.
My other concern is positioning the windows as this needs to be client-
driven, but if I'm not completely mistaken newer versions of weston
support that already. I already digged a bit into the XWayland source
and find it pretty hard to read, so I'm not sure how easy that is. This
will probably also lead to changes on the compositor side.

Solution c) is implementing my own compositor on top of wlroots or
building upon something like cage.

My thoughts are:
a) is somewhat time-consuming and will probably need many smaller bug
fixes later
b) is easier to get right but is harder for me to do because of my
unfamiliarity with and the readability of the X source code
c) is probably the most time consuming

So, trying to formulate a question: What do you think is the best way
forward regarding maintainability, stability and time consumption? Did
I miss something? I'm very grateful for any hints in the right
direction.

Thanks,
Nicolas

[1]: https://github.com/Hjdskes/cage