Christian Schaller, der das Desktop-Entwicklungsteam bei Red Hat leitet und der Fedora-Desktop in einer Überprüfung der Pläne für Desktop-Komponenten in Fedora 31, erwähnte die Absicht von Red Hat, die aktive Entwicklung der X.Org-Serverfunktionalität einzustellen und beschränken Sie sich nur auf die Beibehaltung der vorhandenen Codebasis und das Debuggen.
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 bei der Entwicklung des X.Org-Servers wurde bereits beobachtet. Trotz des zuvor verwendeten sechsmonatigen Veröffentlichungszyklus Die letzte wichtige Version von X.Org Server 1.20 wurde vor 14 Monaten veröffentlicht und die Vorbereitung auf Version 1.21 ist ins Stocken geraten.
Die Situation kann sich ändern, wenn sich ein Unternehmen oder eine Community verpflichtet, die Funktionalität des X.Org-Servers weiter zu verbessern. Angesichts der weit verbreiteten Verlagerung von bedeutenden Projekten nach Wayland ist es jedoch unwahrscheinlich, dass es jemanden geben 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
Die Notwendigkeit, eine Reihe offener Probleme mit Wayland zu lösen, wird ebenfalls erwähnt: So arbeiten Sie mit proprietären NVIDIA-Treibern und optimieren den XWayland DDX-Server, um einen qualitativ hochwertigen Start von X-Anwendungen in einer Wayland-basierten Umgebung sicherzustellen.
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. Zum Beispiel, um Skalierungsprobleme zu lösen, wenn ältere Spiele mit niedriger Bildschirmauflösung ausgeführt werden.
Zusätzlich Die Unterstützung für Waylands Arbeit an Systemen mit NVIDIA-eigenen Treibern muss verbessert werden:
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).
Zusätzlich Es wird daran gearbeitet, PulseAudio und Jack durch PipeWire Media Server zu ersetzen. Dies erweitert die Funktionen von PulseAudio um Video-Streaming und Audioverarbeitung mit minimaler Latenz, berücksichtigt die Anforderungen professioneller Soundverarbeitungssysteme und bietet ein erweitertes Sicherheitsmodell für die Zugriffskontrolle auf Geräteebene.
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.
zu Fedora 31 soll außerdem die Möglichkeit bieten, Qt-Anwendungen in einer auf Gnome basierenden Wayland-Sitzung zu starten. Verwenden des Qt Wayland-Plugins anstelle des XCB-Plugins mit X11 / XWayland.