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

Christian Schaller, Leiter der Desktop-Systementwicklungsgruppe bei Red Hat und im Fedora Desktop Team, hat in einer Übersicht über die Pläne, die sich auf die Desktop-Komponenten in Fedora 31 beziehen, erwähnt, dass Red Hat die aktive Entwicklung der X.Org-Server-Funktionalität einstellen und sich nur noch auf die Pflege des bestehenden Codes und die Behebung von Fehlern beschränken möchte.

Aktuell trägt Red Hat maßgeblich zur Entwicklung des X.Org-Servers bei und ist für dessen Wartung verantwortlich. Daher ist es unwahrscheinlich, dass bedeutende neue Versionen des X.Org-Servers nach einer Abkehr von der Entwicklung weiterhin erscheinen werden. Trotz der Einstellung der Entwicklung wird die Unterstützung für X.Org durch Red Hat jedoch mindestens bis zum Ende des Lebenszyklus von RHEL 8, der bis 2029 dauert, fortgesetzt.

Die Stagnation in der Entwicklung des X.Org-Servers ist bereits jetzt zu beobachten - trotz des zuvor angewandten sechsmonatigen Release-Zyklus wurde die letzte bedeutende Version, X.Org Server 1.20, vor 14 Monaten veröffentlicht, und die Vorbereitungen für die Version 1.21 stehen still. Die Situation könnte sich ändern, wenn ein Unternehmen oder eine Gemeinschaft die Funktionalität des X.Org-Servers weiterentwickelt, aber angesichts der weitreichenden Verlagerung wichtiger Projekte in Richtung Wayland ist es unwahrscheinlich, dass sich Interessenten finden.

Red Hats Hauptaugenmerk liegt derzeit auf der Verbesserung der Desktop-Erfahrung auf Basis von Wayland. Die Überführung des X.Org-Servers in den Wartungsmodus wird erwartet, nachdem die Herausforderung gelöst ist, die Abhängigkeiten von X.Org-Komponenten vollständig zu entfernen und den GNOME Shell-Betrieb ohne XWayland zu ermöglichen, was eine Umstrukturierung oder Beseitigung der verbleibenden Bindungen an X.Org erfordert. Solche Bindungen sind aus dem GNOME Shell fast vollständig entfernt, bestehen jedoch noch im GNOME Settings-Daemon. In GNOME 3.34 oder 3.36 ist geplant, vollständig von den Bindungen an X.Org abzusehen und den Betrieb von XWayland zu organisieren. dynamisch, falls Komponenten zur Gewährleistung der Kompatibilität mit X11 benötigt werden.

Es wird auch auf die Notwendigkeit hingewiesen, eine Reihe von offenen Problemen mit Wayland zu lösen, wie die Unterstützung proprietärer NVIDIA-Treiber und die Weiterentwicklung des XWayland DDX-Servers, um die qualitativ hochwertige Ausführung von X-Anwendungen in einer Wayland-basierten Umgebung zu ermöglichen. Bei den Arbeiten zur Vorbereitung von Fedora 31 wird die Implementierung der Möglichkeit zum Starten von X-Anwendungen mit Root-Rechten unter XWayland hervorgehoben. Ein solcher Start ist aus sicherheitstechnischer Sicht fragwürdig, jedoch notwendig, um die Kompatibilität mit X-Anwendungen sicherzustellen, die erhöhte Berechtigungen benötigen.

Eine weitere Aufgabe besteht darin, die Unterstützung von Wayland in der SDL-Bibliothek zu verbessern, insbesondere um Probleme mit der Skalierung beim Ausführen älterer Spiele in niedrigen Bildschirmauflösungen zu lösen. Es wird auch darauf hingewiesen, dass die Unterstützung von Wayland in Systemen mit proprietären NVIDIA-Treibern verbessert werden muss. Obwohl Wayland bereits seit langem über solche Treiber arbeiten kann, kann XWayland in dieser Konfiguration derzeit keine Mittel für die hardwarebeschleunigte 3D-Grafik nutzen (geplant ist, die Möglichkeit zu bieten, den x.org-Treiber von NVIDIA für XWayland zu laden).

Zusätzlich wird die Fortsetzung der Arbeiten zur Ablösung von PulseAudio und Jack durch einen Multimedia-Server hervorgehoben. PipeWire, erweitert die Möglichkeiten von PulseAudio durch Mittel zur Verarbeitung von Video-Streams und Audio mit minimalen Latenzen, um den Anforderungen professioneller Audiobearbeitung gerecht zu werden. Zudem wird ein erweitertes Sicherheitsmodell zur Verwaltung des Zugriffs auf Geräte- und Stream-Ebene angeboten. Im Rahmen des Entwicklungszyklus von Fedora 31 liegt der Fokus auf der Anwendung von PipeWire für den gemeinsamen Bildschirmzugriff in Umgebungen, die auf Wayland basieren, einschließlich der Verwendung des Protokolls Miracast.

In Fedora 31 wurde ebenfalls wird geplant die Möglichkeit hinzugefügt, Qt-Anwendungen in einer GNOME-Session, die auf Wayland basiert, mithilfe des Qt Wayland-Plugins anstelle des XCB-Plugins, das X11/XWayland verwendet, zu starten.

Quelle: opennet.ru