Christian Schaller, der das Desktop-Entwicklungsteam bei Red Hat und das Fedora-Desktop-Team leitet, erwähnte in einer Überprüfung der Pläne für Desktop-Komponenten in Fedora 31 die Absicht von Red Hat, die aktive Entwicklung der X.Org-Serverfunktionalität einzustellen und sich auf die Wartung der bestehenden Codebasis und die Beseitigung von Fehlern zu beschränken.
Derzeit leistet Red Hat einen wichtigen Beitrag zur Entwicklung des X.Org-Servers und behält seine Unterstützung bei. Daher ist es im Falle einer Unterbrechung der Entwicklung unwahrscheinlich, dass die Bildung signifikanter X.Org-Serverversionen fortgesetzt wird.
Gleichzeitig wird die Unterstützung von X.Org durch Red Hat trotz Einstellung der Entwicklung mindestens bis zum Ende des RHEL 8-Verteilungslebenszyklus fortgesetzt, der bis 2029 andauern wird.
Die Entwicklung von X.Org ist bereits minimal
Die Stagnation in der Entwicklung des X.Org-Servers ist bereits erkennbar. Trotz des zuvor üblichen sechsmonatigen Veröffentlichungszyklus wurde die letzte bedeutende Version des X.Org-Servers 1.20 vor 14 Monaten veröffentlicht, und die Vorbereitungen für Version 1.21 sind ins Stocken geraten.
Die Situation könnte sich ändern, wenn sich ein Unternehmen oder eine Community dazu verpflichten würde, die Funktionalität des X.Org-Servers kontinuierlich zu erweitern. Angesichts der weit verbreiteten Umstellung bedeutender Projekte auf Wayland ist es jedoch unwahrscheinlich, dass dies jemand tun wird.
Red Hat konzentriert sich derzeit auf die Verbesserung der Wayland-basierten Desktop-Arbeit. Es wird erwartet, dass der X.Org-Server in den Wartungsmodus versetzt wird, nachdem das Problem gelöst wurde, Abhängigkeiten von X.Org-Komponenten vollständig zu entfernen und sicherzustellen, dass die Gnome-Shell ohne Verwendung von XWayland gestartet wird. Dies erfordert ein Refactoring oder das Entfernen der verbleibenden Links zu X.org.
Diese Links werden fast aus der Gnome-Shell entfernt, bleiben jedoch in den Gnome-Einstellungen.
In Gnome 3.34 oder 3.36 ist geplant, die X.Org-Bindungen vollständig zu entfernen und die XWayland-Version dynamisch zu organisieren, wenn Komponenten erforderlich sind, um die X11-Kompatibilität sicherzustellen.
Red Hat konzentriert sich lieber auf Wayland
Ebenfalls erwähnt wird die Notwendigkeit, eine Reihe offener Probleme mit Wayland zu lösen, wie beispielsweise die Zusammenarbeit mit den proprietären Treibern von NVIDIA und die Optimierung des XWayland DDX-Servers, um einen reibungslosen Start von X-Anwendungen in einer Wayland-basierten Umgebung zu gewährleisten.
Von den 31 Aufgaben, die zur Vorbereitung auf Fedora ausgeführt werden, implementiert XWayland die Möglichkeit, X-Anwendungen mit Root-Rechten auszuführen. Eine solche Version ist aus Sicherheitsgründen fraglich, aber erforderlich, um die Kompatibilität mit X-Programmen zu gewährleisten, für die erhöhte Berechtigungen erforderlich sind.
Eine weitere Herausforderung besteht darin, die Wayland-Unterstützung in der SDL-Bibliothek zu verbessern, beispielsweise um Skalierungsprobleme beim Ausführen älterer Spiele zu lösen, die mit niedrigen Bildschirmauflösungen laufen.
Darüber hinaus besteht die Notwendigkeit, die Unterstützung für die Wayland-Funktionalität auf Systemen mit proprietären NVIDIA-Treibern zu verbessern:
Wenn Wayland lange Zeit mit solchen Treibern arbeiten kann, kann XWayland in dieser Konfiguration noch keine Hardwarebeschleunigungsfunktionen für 3D-Grafiken verwenden (es ist geplant, x.org NVIDIA-Treiber für XWayland herunterzuladen).
Darüber hinaus wird daran gearbeitet, PulseAudio und Jack durch den PipeWire-Medienserver zu ersetzen, der die Fähigkeiten von PulseAudio um Videostreaming und Audioverarbeitung mit minimaler Latenz erweitert und dabei die Bedürfnisse professioneller Tonverarbeitungssysteme berücksichtigt. Außerdem bietet er ein verbessertes Sicherheitsmodell für die Zugriffskontrolle auf Ebene einzelner Geräte.
Schließlich konzentriert sich die Arbeit im Rahmen des Fedora 31-Entwicklungszyklus auf die Verwendung von PipeWire, um den Zugriff auf den Bildschirm in Wayland-basierten Umgebungen gemeinsam zu nutzen, einschließlich der Verwendung des Miracast-Protokolls.
Fedora 31 plant außerdem, die Möglichkeit hinzuzufügen, Qt-Anwendungen in einer Gnome-basierten Wayland-Sitzung mit dem Qt Wayland-Plugin anstelle des XCB-Plugins unter Verwendung von X11/XWayland zu starten.