Bild: Andreas Martini

Generationswechsel

Linux-Grafikarchitektur: Wayland etabliert sich, aber X-Server bleiben

Mit Wayland gewinnt eine modernere und sichere Grafik-Architektur für Linux-Desktops stetig an Boden. Der Vormarsch beeinträchtigt die Pflege des altbekannten X-Servers, von dem kleinere Desktop-Umgebungen noch eine Weile abhängen.

Von Thorsten Leemhuis

X11 ist tot, lang lebe X11 – das klingt paradox, beschreibt die Lage in der Linux-Welt aber dennoch akkurat. Dort entwickelt Wayland sich zur tragenden Säule großer Desktop-Umgebungen wie Gnome oder KDE. Damit drängt es den X-Server zurück, mit dem Distributionen viele Jahre die Bedienoberfläche auf den Schirm hievten. X-Server und das von ihnen implementierte X11-Protokoll werden Linux-Anwendern trotzdem in Form eines altbekannten sowie eines halbneuen X-Servers noch lange erhalten bleiben. Der ältere stagniert aber schon, was für Cinnamon, Xfce und kleinere Desktops zum Problem werden dürfte.

Doch zuerst zurück zu Wayland, denn dieser modernere und sichere Baustein für Linux-Desktops [1] macht gerade mehrere bedeutende Entwicklungsschritte.

Beim kürzlich veröffentlichtem Ubuntu Desktop 21.04 (siehe S. 92) läuft die Gnome-basierte Bedienoberfläche standardmäßig im Wayland-Modus. Mit Version 17.10 hatte die Distribution das schon einmal gewagt, schwenkte mit Ausgabe 18.04 wieder zum X11-Modus zurück.

Fortschritte bei Gnome und Anwendungen sind ein Grund, warum Ubuntu Desktop mit Version 21.04 zum zweiten Mal den Wechsel auf Wayland wagt.

Gnome hat in den letzten Jahren viel Feinschliff von seinen Entwicklern erhalten, die sich schon lange enorm für Wayland engagieren. Viele Macken und Eigenarten des Wayland-Modus der Gnome-Shell sind dadurch verschwunden, er läuft dieser Tage deutlich runder. Deshalb wagt Ubuntu Desktop es jetzt erneut. Allerdings bleiben nach wie vor einige Dinge zu wünschen übrig. Beispielsweise unterstützen weder das Wayland-Protokoll noch die Gnome-Shell Bildschirme mit HDR (High Dynamic Range), aber das kann der altbekannte X-Server auch nicht.

Der Wayland-Modus von KDE Plasma reift ebenfalls stetig. Dort gibt es noch deutlich mehr Funktionslücken als bei der Gnome-Shell, aber die gehen KDE-Entwickler gerade mit hohem Tempo an. Sie sehen die Alltagstauglichkeit dieser Betriebsart langsam in Reichweite kommen. Die Fedora-Macher preschen derweil vor: Bei der Variante „Fedora 34 KDE Plasma Desktop“ (siehe S. 90) läuft Plasma standardmäßig im Wayland-Modus. Es ist die erste größere Distribution, die diesen Schritt wagt.

Den KDE-Plasma-Entwicklern sind zwar noch einige Defizite des Wayland-Modus bewusst, trotzdem nutzt Fedora 34 KDE Plasma Desktop diesen schon standardmäßig.

Viele Entwickler von Linux-Programmen haben ihre Software in den letzten Jahren angepasst, sodass die Programme Wayland grundsätzlich unterstützen; einige sind sogar speziell auf Eigenarten der Wayland-Modi von Gnome Shell und KDE Plasma abgestimmt. Motivator dafür waren Distributionen, die Gnome schon länger standardmäßig im Wayland-Modus einsetzen. Dazu zählen neben Fedora Workstation und den Enterprise-Linuxen von Red Hat und Suse auch Debian GNU/Linux, sofern man dort Gnome als Desktop wählt.

Microsoft nutzt Wayland als Kernkomponente von WSLg (Windows Subsystem for Linux GUI), mit dem sich grafische Linux-Anwendungen unter Windows ausführen lassen. Diese Funktion steckt in der neuesten Windows Insider Preview (siehe S. 50). Hinter den Kulissen arbeitet der Display-Server Weston, der ursprünglich als Referenzimplementierung zusammen mit Wayland entwickelt wurde.

Auch mit Nvidias proprietären Treibern soll es bald möglich sein, auf X11 angewiesene Anwendungen performant unter Wayland-Desktops auszuführen. Bei quelloffenen Grafiktreibern gelingt das schon lange mit Hilfe von Xwayland, einem X-Server, der als unsichtbarer Mittler zwischen X11-Software und Desktop agiert. Dadurch laufen etwa viele für Linux gemachte Spiele auch unter den Wayland-Modi von Gnome-Shell und Plasma. Mit Nvidias Treibern können mit Xwayland ausgeführte Spiele aber bislang keine Hardware-Beschleunigung nutzen, was diese Modi äußerst unattraktiv macht. Die im Sommer erwartete Versionsreihe 470 des Nvidia-Treibers soll das Problem lösen; dazu ist sie aber aufVerbesserungen in Xwayland angewiesen, die erst dessen nächste Version bringen wird.

Trotz dieser Fortschritte ist die Bildkomposition mithilfe von Wayland noch meilenweit von der dominierenden Stellung entfernt, die der bekannteste X-Server von X.org über 15 Jahre lang innehatte. Mit der aktuellen Entwicklung setzt Wayland seinen Erfolgskurs indes fort und etabliert sich.

Wetterfahne

Das verdankt Wayland zu großen Teilen der Rückendeckung der Gnome- und KDE-Entwickler. Die haben enorm viel Arbeit in die Wayland-Modi ihrer Desktops gesteckt und tun das noch immer. Kein Wunder, denn Wayland verhilft ihnen zu einer robusteren, schlankeren, flexibleren und moderneren Display-Architektur [1]; durch sie hinken sie auch in puncto Sicherheit nicht mehr meilenweit hinter anderen Betriebssystemen hinterher, sondern stechen diese aus.

Bei beiden Camps ist eine Kehrtwende daher äußert unwahrscheinlich. Im Gegenteil: Gnome-Entwickler lassen immer wieder durchscheinen, den Code zur Darstellung via X11-Protokoll und X-Server aus der Gnome-Shell und deren Unterbau Mutter entfernen zu wollen. Gut möglich, dass das schon in ein oder zwei Jahren auf den Tisch kommt. Irgendwann dürfte das auch bei Plasma und dessen Basis Kwin zur Debatte stehen.

Ausgelagert

Auch Fedora/Red Hat und einige andere Distributoren wollen den bekanntesten X-Server von X.org lieber heute als morgen loswerden, obwohl er ihnen viele Jahre treue Dienste geleistet hat. Der Server selbst heißt übrigens „Xorg“ (ohne Punkt), weil man ihn über diese Bezeichnung startet. In ihm sehen manche Distributions- und Desktop-Entwickler eine unnötige Abstraktion und ein Sicherheitsrisiko, auch weil der Code sehr komplex ist und zum Teil aus den Achtzigern stammt; zugleich muss der X-Server bei manchen Grafiktreibern mit Root-Rechten laufen, was ihn zu einem attraktiven Angriffsziel macht.

Doch auch diesen Distributoren ist klar, dass sie Xwayland lange Jahre brauchen werden, um die vielen für X11 geschriebenen Anwendungen unter Wayland-Desktops ausführen zu können. Um diesen als unsichtbaren Mittler agierenden X-Server zu bauen, brauchte man bis vor Kurzem das Quellcodearchiv von Xorg. Dieses entsteht aus einem Git-Repository, aus dem auch Archive für andere X-Server des X.org-Projekts hervorgehen, darunter „XQuartz“ für macOS. Seit dem Frühjahr lässt sich aus dem Repository nun ein Archiv ableiten, das nur das für Xwayland benötigte enthält. Auf diese Weise entstand im März erstmals ein eigenständiges Xwayland-Release mit der Versionsnummer 21.1. Dieses bringt lediglich 11 MByte auf die Waage, während es bei Xorg satte 39 MByte sind.

Abstellgleis in Sicht

Die Codebereiche, die in Xwayland einfließen, wollen einige Entwickler langfristig weiter pflegen. Derweil mangelt es aber schon länger an Leuten, die Xorg selbst betreuen. Zuletzt haben vor allem Red-Hat-Mitarbeiter diesen X-Server gepflegt. Sie scheren sich aber mittlerweile nicht mehr darum, weil Red Hat voll hinter Wayland und Xwayland steht. Das gilt auch für die meisten anderen Entwickler und Firmen, die früher viel zu Xorg beigetragen haben. Deshalb findet sich schon seit einer Weile niemand, der ein neues Major-Release vorbereitet und freigibt. Das wäre aber nötig, um zwischenzeitlich in den Hauptentwicklungszweig eingeflossene Verbesserungen unter die Leute zu bringen. Die letzte Version mit größeren Überarbeitungen ist das im Mai 2018 veröffentlichte Xorg 1.20. Für neue Minor-Versionen mit Sicherheitskorrekturen sorgen einige Entwickler immerhin noch.

Die Stagnation lässt erwarten, dass der lange dominante X-Server dauerhaft keine Rolle mehr spielt. Bis es so weit ist, dürfte die Erde die Sonne aber noch viele Male umkreisen. Die Entwickler von Gnome-Shell und KDE Plasma haben zwar nach vielen Jahren harter Arbeit schon allerlei Grundprobleme gelöst, die Nachzüglern erspart bleiben. Dennoch ist es viel Aufwand, Desktop-Umgebungen wie Cinnamon, Mate, LXQt oder Xfce so umzubauen, damit sie mithilfe von Wayland und anderen Techniken auch ohne X-Server laufen.

An Anmeldebildschirmen lässt sich festlegen, ob Gnome-Shell oder KDE Plasma im Wayland- oder X11-Modus starten.

Kristallkugel

Abzuwarten bleibt, wie sich die Stagnation bei Xorg auf Erfolg und Misserfolg von Desktops auswirkt, die ihn brauchen. Fürs Erste sind für viele Nutzer keine nennenswerten Nachteile absehbar. Durch Fortschritte bei Hard- und Software entstehen mit der Zeit aber oft welche, die Nutzer zu spüren bekommen.

Universelle Wayland Compositors oder Bibliotheken mit Grundfunktionen könnten kleineren Desktops den Technologiesprung erleichtern. Zur Klasse der Universellen gehört „Mir“ von Canonical, der einige Jahre mit Wayland konkurriert hat; mittlerweile ist Mir ein auf Wayland aufbauender Display-Server, der vor allem zum Bau von Bedienoberflächen für IoT-Geräte gedacht ist. Mit Libtaiwins, Taiwins, Weston und Wlroots gibt es noch andere Ansätze, die Desktop-Entwicklern die Nutzung von Wayland erleichtern. Doch auch mit ihnen ist so ein Wechsel aufwendig. Daher bleibt abzuwarten, welche Desktops den Umstieg überhaupt angehen. Beim Tiling Window Manager i3 wird das vermutlich nie passieren: Mit Sway gibt es schon einen auf Wayland aufbauende Bedienoberfläche, die als Eins-zu-Eins-Ersatz für i3 taugt und sogar dessen Konfigurationsdatei versteht.

Relativ sicher ist indes, dass X11 langfristig zu den Akten gelegt wird. Zwar finden sich vermutlich nochmal Leute, die neue Versionen von Xorg freigeben. Aber es ist äußert unwahrscheinlich, dass diese die vielen Defizite des Ansatzes angehen, der in Teilen aus den Achtzigern stammt. Im Bezug auf Sicherheit und Funktionsumfang hinkt er der Zeit schon lange hinterher, daher wäre das enorm viel Arbeit; zugleich müssten Programmierer den Code auch noch an die Hardware und die Ansprüche von morgen anpassen, um nicht noch mehr ins Hintertreffen zu geraten.

Einen so grundlegenden Umbau von Xorg scheuten daher sogar viele seiner wichtigsten Entwickler. Sie haben sich früh hinter Wayland gestellt, das schließlich aus ihrer Mitte entstand. Deshalb ist es trotz der Konkurrenzsituation auch beim X.org-Projekt angesiedelt. Genau wie die X Foundation fördert das Projekt die Entwicklung von Wayland sogar aktiv und behält so auf Dauer eine Existenzberechtigung. (ktn@ct.de)

Vom Irrglauben, Wayland ersetze den X-Server

Landläufig gilt Wayland als Nachfolger des X-Servers Xorg, mit dem Linux-Distributionen viele Jahre grafische Bedienoberflächen auf den Bildschirm gehievt haben. Diese Einstufung führt aber gehörig in die Irre: Nicht Wayland, sondern Desktops wie Gnome-Shell/Mutter oder Plasma/Kwin beerben den X11 implementierenden X-Server Xorg. Wayland kann diesen auch gar nicht ersetzen: Ähnlich wie X11 ist es in erster Linie ein Protokoll, über das Desktops und Anwendungen interagieren; zugleich meint der Begriff Wayland aber auch eine Softwarebibliothek, die das gleichnamige Protokoll implementiert [1].

Beiden fehlen aber für Display-Server wichtige Funktionen, etwa zur Bildschirmansteuerung. Parallelen zwischen Wayland und X11 zu ziehen ist ohnehin, als würde man Äpfel und Brokkoli vergleichen: Noch mehr daneben, als ein Äpfel-und-Birnen-Vergleich. Denn Wayland ist viel simpler und geht ganz anders vor als X11. Im Wesentlichen ermöglicht es nur zwei Dinge: Events von Eingabegeräten sowie Speicherbereiche zwischen einem als „Server“ agierenden Compositor eines Desktops und darunter laufenden Programmen auszutauschen. Letztere gelten als „Client“ und müssen ihre Bedienoberfläche komplett selbst in die erwähnten Speicherbereiche hineinschreiben. Das erledigen Bibliotheken wie GTK und Qt; vieles dazu nötige konnten sie schon vor Wayland, weil sie es auch beim X-Server schon weitgehend so machen und so X11 zum Teil umgehen.

Für sich allein sind Wayland-Protokoll und -Implementierung aber kaum zu etwas zu gebrauchen. Das ändert sich, wenn Desktops sie mit Linux-Techniken wie Kernel-based Mode-Setting (KMS), Generic Buffer Manager (GBM), Mesa 3D Graphics Library und Libinput kombinieren: Mit diesem Konglomerat sind Desktops in der Lage, ohne X11 und X-Server auszukommen. Ihre Compositor oder Window Manager werden dadurch selbst zum Display-Server und gelten dann auch als Wayland Compositor. Als solche müssen sie sich aber auch selbst um zahlreiche Aufgaben kümmern, die zuvor der X-Server für die Desktops erledigt hat – allen voran die Konfiguration und Handhabung von Bildschirmen und Eingabegeräten sowie die Bildausgabe via GBM. Nvidias proprietärer Treiber beherrscht diese Technik nicht; Desktops, die ihn im Wayland-Modus unterstützen wollen, müssen für ihn daher Extra-Code enthalten.

Letztlich ersetzen daher Desktops den X-Server, und nicht Wayland. Was nach einer Spitzfindigkeit klingt, ist für das Verständnis aber essenziell. Denn ein „Wayland ersetzt den X-Server“ legt den Schluss nahe, beides seien gegeneinander austauschbare Fundamente für den Betrieb von Desktop-Oberflächen. Das ist aber fern der Realität. Aussagen wie „Ubuntu 21.04 nutzt jetzt standardmäßig Wayland“ sind daher irreführend: Nur bei der korrekt „Ubuntu Desktop“, aber oft schlicht „Ubuntu“ genannten Ausgabe der Distributionsfamilie läuft die Bedienoberfläche jetzt im Wayland-Modus. Andere Varianten bleiben beim X-Server Xorg. Abgesehen von Kubuntu müssen sie das auch, denn sie haben keine Wahl: Cinnamon, Mate, LXQt oder Xfce und viele andere Desktops bieten noch gar keinen Wayland-Modus und sind daher auf den X-Server angewiesen.

Netzwerktransparenz: einerseits da, andererseits noch unfertig

Eine Eigenschaft von Wayland sorgt immer wieder für Streit und Kritik: Das Protokoll bietet rein gar nichts, um eine grafische Anwendung auf einem per SSH angesprochenen System zu starten, deren Benutzeroberfläche aber lokal anzuzeigen. Ein solches Feature passt schlicht nicht zur Arbeitsweise von Wayland, weil das Datenaufkommen und die Latenzen dazu viel zu groß wären. Dennoch klappt das Beschriebene ganz gewohnt per SSH, selbst wenn Gnome-Shell oder KDE Plasma im Wayland-Modus laufen.

Das ist Xwayland zu verdanken, denn damit funktioniert X-Forwarding per SSH wie eh und je. Dazu muss man der Software aber womöglich untersagen, sich mit dem Desktop des entfernten Systems zu verbinden, sofern da denn einer läuft. Außerdem muss die Anwendung in der Lage sein, ihre Bedienoberfläche per X11 auszugeben. Die dafür zuständigen X11-Backends dürften Entwickler aber irgendwann beerdigen wollen. Langfristig muss daher eine andere Lösung her. Für die sprechen ohnehin weitere Gründe, vor allem einer: D-Bus sowie gängige Grafik-Toolkits wie GTK und Qt sind im klassischen Sinne schon länger nicht mehr „netzwerktransparent“. X11-Forwarding funktioniert zwar trotzdem mit vielen Anwendungen, läuft aber oft nicht ganz rund.

Es gibt bereits mehrere Lösungen, um entfernt mit Wayland laufende Desktops oder einzelne Programme wie lokal gestartete zu nutzen. Die namhaftesten sind Waypipe und Wayvnc sowie die auf PipeWire aufbauenden Desktop-Freigaben von Gnome-Shell und Plasma. Bei diesen Ansätzen erfolgt der Datenaustausch oftmals über bekannte Remote-Desktop-Protokolle wie VNC oder RDP. Ferner gibt es Überlegungen, sich die Video-Kompressionsfunktionen moderner Grafikkerne zunutze zu machen. Diese Lösungen bieten vielfach Performance-Vorteile, insbesondere bei der Interaktion über träge Verbindungen: Aufgrund großer Latenzen und historischem Ballast funktioniert X11-Forwarding gerade dort mehr schlecht als recht.

X11-Forwarding hat aber einen großen Vorteil: Über eine simple SSH-Option lässt es sich bei den meisten Distributionen im Handumdrehen verwenden. Diese Einfachheit ist vielen Anwendern an Herz gewachsen und fehlt den Ansätzen für Wayland noch.