Dual-head kiosk/embedded application

[Carsten Haitzler]

On Thu, 06 Aug 2020 09:02:49 +0200 Nicolas Jeker <n.jeker at gmx.net> said:

path a.

> 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
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com