From Fedora Project Wiki
m (fix typing mistake)
 
(13 intermediate revisions by 3 users not shown)
Line 13: Line 13:
 
This should link to your home wiki page so we know who you are.  
 
This should link to your home wiki page so we know who you are.  
 
-->
 
-->
* Name: [[User:ofourdan| Olivier Fourdan]]
+
* Name: [[User:ofourdan| Olivier Fourdan]], [[User:mdaenzer| Michel Dänzer]]
 
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
 
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: ofourdan@redhat.com
+
* Email: <ofourdan@redhat.com>, <mdaenzer@redhat.com>
 
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
 
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
 
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
 
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
Line 25: Line 25:
  
 
== Current status ==
 
== Current status ==
[[Category:ChangePageIncomplete]]
+
[[Category:ChangeAcceptedF34]]
 
<!-- When your change proposal page is completed and ready for review and announcement -->
 
<!-- When your change proposal page is completed and ready for review and announcement -->
 
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
 
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 44: Line 44:
 
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
 
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
 
-->
 
-->
* FESCo issue: <will be assigned by the Wrangler>
+
* FESCo issue: [https://pagure.io/fesco/issue/2515 #2515]
* Tracker bug: <will be assigned by the Wrangler>
+
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1908881 #1908881]
* Release notes tracker: <will be assigned by the Wrangler>
+
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/616 #616]
  
 
== Detailed Description ==
 
== Detailed Description ==
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 ==
Line 113: Line 113:
 
===Xwayland pkgconfig file===
 
===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.
 
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)
+
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===
 
===Maintainability===
Line 128: Line 128:
 
Rebuild Xwayland dependent package if they want to benefit from the new features exposed from the command line (e.g. initfd)
 
Rebuild Xwayland dependent package if they want to benefit from the new features exposed from the command line (e.g. initfd)
  
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+
* Release engineering: [https://pagure.io/releng/issues/9865 #9865] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
 
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
 
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
 
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
Line 171: Line 171:
 
* No config file are involved   
 
* No config file are involved   
 
* Test for non regression with X11 clients as compared with xorg-x11-server-Xwayland from the stable branch   
 
* 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 Steam games for non regression
+
* 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 ==
 
== User Experience ==
Line 205: Line 208:
  
 
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
 
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+
* Contingency mechanism: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 +
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.
 +
 
 
<!-- 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. -->
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
 
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
 
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+
* Contingency deadline: beta freeze
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
+
* Blocks release: No
 
+
* Blocks product: No
* 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
 
  
 
== Documentation ==
 
== Documentation ==

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

Current status

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.

Release Notes