m (delete surplus for) |
m (fix typing mistake) |
||
Line 213: | Line 213: | ||
Rebuild mutter to not use initfd | Rebuild mutter to not use initfd | ||
Downgrading to xorg-x11-server-Xwayland from the stable branch | Downgrading to xorg-x11-server-Xwayland from the stable branch would require a user action, in case the contingency plan is triggered. | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> |
Latest revision as of 22:24, 3 January 2021
Xwayland as a standalone package
Summary
Move Xwayland to a standalone package built from current code upstream rather than the stable branch.
Owner
- Name: Olivier Fourdan, Michel Dänzer
- Email: <ofourdan@redhat.com>, <mdaenzer@redhat.com>
Current status
- Targeted release: Fedora 34
- Last updated: 2021-01-03
- FESCo issue: #2515
- Tracker bug: #1908881
- Release notes tracker: #616
Detailed Description
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 git snapshots of the current code upstream rather than the stable branch.
Feedback
None yet.
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.
initfd support
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 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 Xwayland opens for that possibility)
Maintainability
With Xwayland receiving most of the attention upstream, that will allow for new features to be available for Fedora users faster and more easily.
Scope
- 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: #9865 (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:
Upgrade/compatibility impact
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
- Xwayland supports EGLStream so it needs non regression testing with NVidia closed-source driver
- No config file are involved
- Test for non regression with X11 clients as compared with xorg-x11-server-Xwayland from the stable branch
- Test must include demanding X11 clients such as games for non regression (Steam?)
To ease testing, a COPR with the standalone package for Fedora 33 and rawhide is available here: https://copr.fedorainfracloud.org/coprs/ofourdan/Xwayland/
User Experience
Users should not see any change (it's the same Xwayland program, just built from a different branch from upstream).
Dependencies
The current packages which list xorg-x11-server-Xwayland as dependency are:
- gamescope
- gnome-session-wayland-session
- kwin-wayland
- plasma-workspace-wayland
- sway
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 Plan
- Contingency mechanism:
Switch back to building Xwayland from the stable branch (xorg-x11-server-Xwayland).
Rebuild mutter to not use initfd
Downgrading to xorg-x11-server-Xwayland from the stable branch would require a user action, in case the contingency plan is triggered.
- Contingency deadline: beta freeze
- Blocks release: No
- Blocks product: No
Documentation
There is no documentation change required.