Red Hat beabsichtigt, die Entwicklung des X.Org-Servers einzustellen

Christian Schaller, der die Gruppe für die Entwicklung von Desktop-Systemen bei Red Hat und im Fedora Desktop Team leitet, im Überblick über die Pläne, bezüglich der Komponenten des Desktops in Fedora 31, erwähnte die Absicht von Red Hat, die aktive Entwicklung der Funktionalität des X.Org-Servers einzustellen und sich lediglich auf die Wartung der bestehenden Code-Basis sowie die Behebung von Fehlern zu beschränken.

Derzeit leistet Red Hat einen entscheidenden Beitrag zur Entwicklung des X.Org-Servers und trägt die Verantwortung für dessen Wartung. Daher ist es unwahrscheinlich, dass die Entwicklung wesentlicher Releases des X.Org-Servers fortgesetzt wird, falls Red Hat sich aus der Entwicklung zurückzieht. Trotz der Einstellung der Entwicklung wird die Wartung von X.Org durch Red Hat mindestens bis zum Ende des Lebenszyklus der Distribution RHEL 8 fortgesetzt, die bis 2029 dauern wird.

Die Stagnation in der Entwicklung des X.Org-Servers ist bereits jetzt zu beobachten – trotz des früher angewandten sechsmonatlichen Zyklus für die Freigabe von Versionen wurde die letzte größere Veröffentlichung, X.Org Server 1.20, vor 14 Monaten veröffentlicht, und die Vorbereitung der Version 1.21 kommt nicht voran. Die Situation könnte sich ändern, wenn ein Unternehmen oder eine Gemeinschaft die Fortsetzung der Entwicklung des X.Org-Servers übernehmen würde. Angesichts des weitreichenden Wandels bedeutender Projekte in Richtung Wayland ist es jedoch unwahrscheinlich, dass sich Interessierte finden lassen.

Derzeit konzentriert sich Red Hat auf die Verbesserung der Desktop-Nutzung auf Basis von Wayland. Die Umstellung des X.Org-Servers auf einen Wartungsmodus wird erwartet, nachdem das Problem der vollständigen Entfernung der Abhängigkeit von X.Org-Komponenten und der Gewährleistung des Starts von GNOME Shell ohne Verwendung von XWayland gelöst wurde. Dies erfordert eine Umstrukturierung oder die Entfernung von verbleibenden Bindungen an X.Org. Solche Bindungen sind bereits fast aus GNOME Shell ausgeschlossen, verbleiben jedoch noch im GNOME Settings-Daemon. In GNOME 3.34 oder 3.36 ist geplant, völlig auf Bindungen an X.Org zu verzichten und XWayland dynamisch zu starten, wenn Bedarf an Komponenten zur Sicherstellung der Kompatibilität mit X11 besteht.Außerdem wird die Notwendigkeit erwähnt, eine Reihe

von verbleibenden Problemen zu lösen. verbleibenden Problemen zu lösen. Mit Wayland, wie die Zusammenarbeit mit proprietären NVIDIA-Treibern und der Anpassung des DDX-Servers XWayland zur Qualitätssicherung des Starts von X-Anwendungen in einer Umgebung auf Basis von Wayland. Bei den Arbeiten im Rahmen der Vorbereitung von Fedora 31 wird die Implementierung der Möglichkeit zum Starten von X-Anwendungen mit Root-Rechten in XWayland hervorgehoben. Ein solcher Start ist aus sicherheitstechnischer Sicht fragwürdig, jedoch notwendig, um die Kompatibilität mit X-Programmen sicherzustellen, die für ihre Funktion erhöhte Privilegien benötigen.

Eine weitere Aufgabe besteht darin, die Unterstützung von Wayland in der SDL-Bibliothek zu verbessern, beispielsweise um Probleme mit der Skalierung beim Starten älterer Spiele, die in niedrigen Bildschirmauflösungen laufen, zu lösen. Es wird auch auf die Notwendigkeit hingewiesen, die Unterstützung von Wayland in Systemen mit proprietären NVIDIA-Treibern zu verbessern – während Wayland schon lange über solche Treiber funktioniert, kann XWayland in dieser Konfiguration derzeit keine Mittel zur Hardwarebeschleunigung von 3D-Grafik nutzen (es ist geplant, die Verwendung des x.org-Treibers von NVIDIA für XWayland zu ermöglichen).

Zusätzlich wird die Fortführung der Arbeiten zur Ablösung von PulseAudio und Jack durch einen Multimedia-Server angemerkt PipeWire, der die Möglichkeiten von PulseAudio mit Funktionen zur Arbeit mit Video-Streams und zur Verarbeitung von Audio mit minimalen Latenzen unter Berücksichtigung der Bedürfnisse professioneller Audiobearbeitung erweitert und ein erweitertes Sicherheitsmodell für den Zugriff auf der Ebene einzelner Geräte und Streams bietet. Im Rahmen des Entwicklungszyklus von Fedora 31 liegt der Schwerpunkt der Arbeiten auf der Anwendung von PipeWire zur Organisation des gemeinsamen Zugriffs auf den Bildschirm in Umgebungen auf Basis von Wayland, einschließlich der Nutzung des Protokolls Miracast.

In Fedora 31 wird auch es ist geplant die Möglichkeit hinzugefügt, Qt-Anwendungen in einer GNOME-Sitzung auf Basis von Wayland mit dem Qt Wayland-Plugin anstelle des XCB-Plugins, das X11/XWayland verwendet, zu starten.

Quelle: opennet.ru