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

Pekka Paalanen ppaalanen at
Wed Nov 29 14:02:09 UTC 2023

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


> Cheers
> Olivier
> [1] Red Hat Enterprise Linux 10 plans for Wayland and Xorg server
> <>
> [2]
> [3]
> [4]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the wayland-devel mailing list