From Fedora Project Wiki
Line 59: Line 59:
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.
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.
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 ==
== Feedback ==

Revision as of 10:35, 25 November 2020


Xwayland as a standalone package

Summary

Move Xwayland to a standalone package built from current code upstream rather than the stable branch.

Owner

Current status

  • 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>

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 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)

  • 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?)

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 wpuld 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.

Release Notes