On Thu, 06 Aug 2020 09:02:49 +0200 Nicolas Jeker <n.je...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
