Christian Schaller, who leads the desktop development team at Red Hat and the Fedora desktop team, in a review of plans for desktop components in Fedora 31, mentioned Red Hat's intention to stop actively developing X.Org server functionality and limit itself to maintaining the existing codebase and eliminating bugs.
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.
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 previously used, the last significant version of X.Org Server 1.20 was released 14 months ago, and preparations for version 1.21 are stalled.
The situation could change if a company or community commits to continuing to increase the functionality of the X.Org server, but given the widespread shift of significant projects to Wayland, it is unlikely that anyone will.
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
Also mentioned is the need to resolve a number of outstanding issues with Wayland, such as working with NVIDIA's 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 Wayland support in the SDL library, for example, to solve scaling problems when running older games that run at low screen resolutions.
In addition, there is a need to improve support for Wayland's functionality on systems with proprietary NVIDIA 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 underway to replace PulseAudio and Jack with the 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 improved security model for access control at the individual device level.
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.
Fedora 31 also plans 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.