On Wed, 29 Nov 2023 10:10:05 +0100 Olivier Fourdan <four...@gmail.com> wrote:
> Hi all, > > In Fedora and Red Hat Enterprise Linux, we ship a small shell script called > "xvfb-run" originating from Debian to launch an X11 client within Xvfb. > > With the future removal of Xorg and all related Xservers in RHEL [1], > except Xwayland, there was a need for a replacement utility that would work > like xvfb-run, but without Xvfb :) > > The idea is to run Xwayland rootful within a Wayland compositor headless as > a replacement for Xvfb. The problem though is that I didn't want to be > tight to a specific Wayland compositor and of course every Wayland > compositor uses different options to run headless. > > At the same time, I was also working on improving Xwayland rootful support > ([2], and identified the need for a convenient utility to run an X11 client > within its own Xwayland rootful instance (useful to run a legacy game for > example. as with [3]). > > So, long story short, what started as a replacement utility for xvfb-run > ended as 3 different (yet related) utilities: > > * xwayland-run, to spawn an X11 client within its own dedicated Xwayland > rootful instance, Hi Olivier, wouldn't this one be at home in the xserver repository? > * wlheadless-run to run a Wayland client on a set of supported Wayland > headless compositors, I think this would belong fine in wayland-utils except for needing per-compositor code in it. Having tools that depend on compositor specifics live in wayland-utils would need a consensus agreement. I have nothing against that, but I also don't maintain wayland-utils. Alternatively, maybe each compositor project should consider shipping a short-cut command for a headless instance? Though that does make xwfb-run just eat the differences instead. > * xwfb-run, a combination of the two other tools above to be used as a > direct replacement for xvfb-run specifically. xserver repository? > Right now, it supports 4 different Wayland compositors (weston, cage, > mutter, gnome-kiosk) but adding more should just be a matter of adding a > relevant module. > > So my question is, if there is any interest for such a project [4], should > this be moved to the wayland namespace in gitlab (we could even change the > name of the project), should that be added to the existing > "wayland-utility" project that we have already, or if there's no interest > it's fine to stay in my own gitlab namespace for now? When I was asking to have color-and-hdr documentation repository under any common gitlab group instead of my personal namespace, the answer was that it should first become a true community project that won't die as soon as I walk away from it. Will be interesting to see how much attention your scripts gain. Thanks, pq > > Cheers > Olivier > > [1] Red Hat Enterprise Linux 10 plans for Wayland and Xorg server > <https://www.redhat.com/en/blog/rhel-10-plans-wayland-and-xorg-server?channel=/en/blog/channel/red-hat-enterprise-linux> > [2] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197 > [3] https://gitlab.freedesktop.org/xorg/xserver/-/issues/1595 > [4] https://gitlab.freedesktop.org/ofourdan/xwayland-run
pgpfIDBTIxVMF.pgp
Description: OpenPGP digital signature