Christian Schaller, leading the desktop systems development group at Red Hat and Fedora Desktop Team, in , regarding desktop components in Fedora 31, mentioned Red Hat's intention to cease active development of X.Org server functionality and limit itself only to maintaining the existing codebase and fixing bugs.
Currently, Red Hat is making a significant contribution to the development of the X.Org server and is responsible for its maintenance; thus, in the event of disengagement from development, significant releases of the X.Org server are unlikely to continue. However, despite the halt in development, Red Hat will continue supporting X.Org at least until the end of the lifecycle of the RHEL 8 distribution, which will last until 2029.
Stagnation in the development of the X.Org server is already noticeable – despite the previously used six-month release cycle, the last significant release, X.Org Server 1.20, was published 14 months ago, and the preparation for the 1.21 release is stalled. The situation may change if some company or community takes on the continuation of expanding the functionality of the X.Org server, but given the widespread shift of significant projects towards Wayland, it is unlikely that there will be any volunteers.
Red Hat is currently focusing on improving the desktop experience based on Wayland. The transition of the X.Org server to maintenance mode is expected after the task of completely removing the dependency on X.Org components and ensuring the launch of GNOME Shell without using XWayland is resolved, which requires refactoring or removing the remaining ties to X.Org. Such ties have almost been eliminated from GNOME Shell, but still remain in the GNOME Setting daemon. In GNOME 3.34 or 3.36, it is planned to completely get rid of the ties to X.Org and organize the launch of XWayland , as needed for components to ensure compatibility with X11.
The necessity to address a number of with Wayland, such as working with proprietary NVIDIA drivers and modifying the XWayland DDX server to ensure high-quality launching of X applications in a Wayland-based environment. Among the tasks carried out for the preparation of Fedora 31 is the implementation in XWayland of the ability to launch X applications with root privileges. Such launches are questionable from a security standpoint but necessary for compatibility with X programs that require elevated privileges.
Another task is to improve Wayland support in the SDL library, for example, to address scaling issues when running older games that operate in low screen resolutions. There is also a need to enhance support for Wayland in systems with proprietary NVIDIA drivers — while Wayland has long been able to run on top of such drivers, XWayland in this configuration cannot yet utilize hardware acceleration for 3D graphics (there are plans to provide the ability to load the x.org NVIDIA driver for XWayland).
Additionally, work continues to replace PulseAudio and Jack with a multimedia server , expanding PulseAudio's capabilities with tools for handling video streams and processing audio with minimal latency, taking into account the needs of professional audio processing systems, and also offering an extended security model for managing access at the individual device and stream level. Within the development cycle of Fedora 31, efforts are focused on applying PipeWire for organizing screen sharing in Wayland-based environments, including the use of the protocol .
In Fedora 31, it is also adding the ability to run Qt applications in a GNOME session based on Wayland using the Qt Wayland plugin instead of the XCB plugin, which utilizes X11/XWayland.
Source: opennet.ru
