Introducing xwayland-run, a set of small utilities to run X11 and Wayland clients

[Pekka Paalanen]

On Wed, 29 Nov 2023 10:10:05 +0100
Olivier Fourdan <fourdan at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20231129/9ed316a2/attachment.sig>