On Mon, Nov 30, 2020 at 8:06 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > https://fedoraproject.org/wiki/Changes/XwaylandStandalone > > == Summary == > Move Xwayland to a standalone package built from current code upstream > rather than the stable branch. > > == Owner == > * Name: [[User:ofourdan| Olivier Fourdan]], [[User:mdaenzer| Michel Dänzer]] > * Email: <ofourdan@xxxxxxxxxx>, <mdaenzer@xxxxxxxxxx> > > > == 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. > > > == 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 [[User:Jwrdegoede | 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) > * Release engineering: [https://pagure.io/releng/issues/9865 #9865] > * 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 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. I assume there are also at least *some* improvements (other than XWayland improvements) in the xserver repo that are not released yet? Could we at least get one final, last, xserver release, maybe even with XWayland split out as a separate component upstream? That would make this downstream change easier, and would also benefit all other users of X (e.g. other distros that would like to do something similar to this change proposal). Fabio _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
