Christian Schaller, who leads the desktop development team at Red Hat and the Fedora desktop, in a review of the plans for desktop components in Fedora 31, mentioned Red Hat's intention to stop actively developing X.Org server functionality and be limited only to maintaining the existing code base and debugging.
Currently, Red Hat makes a key contribution to the development of the X.Org server and maintains its support therefore, in the event of suspension of development, it is unlikely that the formation of significant X.Org server releases will continue.
At the same time, despite the cessation of development, Red Hat's support of X.Org will continue at least until the end of the RHEL 8 distribution lifecycle, which will last until 2029.
Table of Contents
The development of X.Org is already minimal
The stagnation in the development of the X.Org server has already been observed. Despite the six-month release cycle that was used previously, the last significant version of X.Org Server 1.20 was released 14 months ago and preparation for version 1.21 is stalling.
The situation may change if any company or community agrees to continue increasing the functionality of the X.Org server, But given the widespread shift from significant projects to Wayland, it is unlikely there will be anyone.
Red Hat is currently focusing on improving Wayland-based desktop work. The X.Org server is expected to be put into maintenance mode after solving the problem of completely removing dependencies from X.Org components and making sure the Gnome shell starts without using XWayland, which requires refactoring or remove the remaining links to X.org.
These links are almost removed from the Gnome Shell but still remain in the Gnome settings.
In Gnome 3.34 or 3.36, it is planned to completely ditch the X.Org bindings and organize the XWayland release dynamically, when the need for components arises to ensure X11 compatibility.
Red Hat prefers to focus its efforts on Wayland
The need to resolve a number of outstanding issues with Wayland is also mentioned, like working with NVIDIA proprietary drivers and refining the XWayland DDX server to ensure quality launch of X applications in a Wayland-based environment.
Of the 31 jobs being done in preparation for Fedora, XWayland is implementing the ability to run X applications with root privileges. Such a release is questionable from a security point of view, but is necessary to ensure compatibility with X programs, which require elevated privileges.
Another challenge is improving the Wayland support in the SDL library, for example, to solve scaling issues when running older games that run at low screen resolutions.
In addition, There is a need to improve support for Wayland's work on systems with NVIDIA proprietary drivers:
if Wayland can work on such drivers for a long time, then XWayland in this configuration cannot yet use hardware acceleration capabilities for 3D graphics (it is planned to provide the ability to download x.org NVIDIA drivers for XWayland).
In addition, work is ongoing to replace PulseAudio and Jack with PipeWire Media Server, which expands the capabilities of PulseAudio with video streaming and audio processing with minimal latency, taking into account the needs of professional sound processing systems, as well as offering an enhanced security model for device-level access control individual.
Finally as part of the Fedora 31 development cycle, the work focuses on the use of PipeWire to share screen access in Wayland-based environments, including the use of the Miracast protocol.
For, Fedora 31 is also planned to add the ability to launch Qt applications in a Gnome-based Wayland session. using the Qt Wayland plugin instead of the XCB plugin using X11 / XWayland.