Xwayland as a standalone package
Move Xwayland to a standalone package built from current code upstream rather than the stable branch.
- Name: Olivier Fourdan
- Email: firstname.lastname@example.org
- Targeted release: Fedora 34
- Last updated: 2020-11-25
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Xorg releases upstream are stuck to the current 1.20 branch for years with no foreseeable future major update.
But Xwayland, the X11 server for Wayland, is receiving quite a lot of updates upstream.
Xwayland has no device dependent driver loaded at run time, doesn't load any module, so it is not limited by the Xorg API versioning like the rest of Xorg.
So technically, there is nothing stopping us from having Xwayland as a standalone separate package built on git master, while the rest of xorg-x11-server comes from the stable tree upstream.
This change is about moving Xwayland to a separate package from the rest of Xorg, built from the current code upstream rather than the stable branch.
Eventually, upstream may chose to release Xwayland separately from the rest of Xorg, for the same reasons. When that happens, we can chose to base the Xwayland standalone package on that release from upstream.
Benefit to Fedora
Xwayland from upstream current code has interesting features missing from the stable branch, some are backported manually in the current Fedora package, but some others aren't.
There are also existing COPRs trying to backport those features, but that can introduce bugs. Using the code from upstream would avoid the appeal or even the need for such backports.
XRandR emulation for games
Those changes from Hans De Goede are already backported in the current Fedora package for each new release, using Xwayland from current code upstream would save us from this backport process, and the potential issues induced by backports.
Multiple window buffers
This is basically "tearfree" for Xwayland applications.
To be able to run Xwayland on demand, the compositor needs a side channel display where it can run the special X11 clients which need to complete before the regular clients are started. That feature is present in Xwayland from current code upstream, and mutter can already make use of it.
Xwayland pkgconfig file
That allows to other packages to know about the Xwayland built options and the Xwayland executable location so that Wayland compositors such as gnome-shell/mutter can adapt to Xwayland features enabled at build time. For example, we could chose to have Xwayland installed in "libexec" path rather than the common "bindir" path, and mutter could start Xwayland from there (that requires changes in mutter though, but the pkg-config for for Xwayland opens for that possibility)
With Xwayland receiving most of the attention upstream, that will allow for new features to be available for Fedora users faster and more easily.
- Proposal owners:
We would make Xwayland a separate package build from git snapshots from upstream. That package would provide Xwayland and Xwayland-devel (for the Xwayland pkg-config file). The existing Xwayland build would be removed from the xorg-x11-server package (stable releases branch).
- Other developers:
Rebuild Xwayland dependent package if they want to benefit from the new features exposed from the command line (e.g. initfd)
- Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)
- Policies and guidelines:
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives:
The standalone Xwayland package obsoletes the existing xorg-x11-server-Xwayland package, so the upgrade would simply replace xorg-x11-server-Xwayland with standalone Xwayland package.
Xwayland requires no configuration file, nothing needs to be updated on the user side.
Features are added, not removed.
How To Test
0. Xwayland supports EGLStream so it needs testing with NVidia closed-source driver 1. No config file are involved 2. Test for non regression with X11 clients as compared with xorg-x11-server-Xwayland from the stable branch 3. Test must include demanding X11 clients such as Steam games for non regression
Users should not see any change (it's the same Xwayland program, just built from a different branch from upstream).
The current packages which list xorg-x11-server-Xwayland as dependency are:
But the standalone Xwayland package would be a drop-in replacement for xorg-x11-server-Xwayland (i.e. it provides xorg-x11-server-Xwayland) so there is no impact on those packages.
- mutter would benefit from being rebuilt against the standalone version of Xwayland to benefit from the initfd option.
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
- Blocks product? product
- Switch back to building Xwayland from the stable branch.
- Rebuild mutter to not use initfd
Contingency deadline: beta freeze Blocks release: No Blocks product: No
There is no documentation change required.