Ab Mitte 2016 soll Wayland in vielen Distributionen den in die Jahre gekommenen X.org-Server ablösen. Unser Test zeigt, dass dieser Plan aufgehen könnte. Dennoch wird uns das alte X-Window-System noch über Jahre erhalten bleiben.

Die Hauptaufgabe eines Display-Servers besteht darin, alle Ein- und Ausgaben seiner Clients zu verarbeiten und untereinander und mit dem Rest des Betriebssystems sowie der Hardware so zu koordinieren, dass auf dem Bildschirm die Elemente eines modernen grafischen Desktops erscheinen (Abbildung 1). Auf dem Linux-Desktop tritt das seit 2008 unter Federführung des Intel-Mitarbeiters Kristian Høgsberg entwickelte Netzwerkprotokoll Wayland an, diese Aufgabe von dem mittlerweile in die Jahre gekommene Display-Server-Protokoll X Window System (X11) zu übernehmen.

Abbildung 1: Der Display-Server zwischen Kernel und Hardware und den Anwendungen.

Das gemäß dem Client-Server-Modell ausgelegte X11 feierte im vergangenen Herbst seinen dreißigsten Geburtstag, seine Ablösung wäre längst überfällig: Der X11-Code gilt als Flickenteppich, der sich nur noch schwierig warten und kaum noch erweitern lässt. Immer wieder tauchen gravierende Fehler auf, die oft seit vielen Jahren unentdeckt im Quelltext schlummern. So entdeckten Entwickler erst 2014 eine Sicherheitslücke im Font-Server, die seit 1991 bestand [1]. Auch die rigoros praktizierte Rückwärtskompatibilität trägt ihren Teil dazu bei, dass X11 als nicht unbedingt sicher gilt. Die Software schleppt Kernkomponenten aus den Anfangstagen mit sich herum, die heute kaum mehr eine Anwendung finden, aber gemäß Standard zur Verfügung stehen müssen.

Auch war die Ausrichtung zu Beginn der X11-Entwicklung aufgrund anderer Anforderungen eine völlig andere als jene, die man von einem modernen Grafikstack erwartet. Fähigkeiten wie das Zeichnen von Kreisen und Rechtecken oder das Verschieben von Fenstern regeln heutige Grafikbibliotheken wesentlich effizienter, ohne dafür auf einen X-Server zurückgreifen zu müssen. Zudem gibt es inzwischen Shared Libraries, sodass grafikfähige Applikationen nicht Unmengen an Grafikfunktionen mitschleppen müssen. Moderne Clients erwarten vom Display-Server lediglich das Zuteilen eines Bereichs, in den sie schreiben dürfen, und das Darstellen dieser Inhalte. Das entspricht exakt der Arbeitsweise von Wayland (Abbildung 2).

Abbildung 2: Wayland im Gefüge des Betriebssystems.

Um- und Abwege

Verantwortlich für die heutige Rolle von Wayland als Erbe von X11 zeichnet jemand, der das Protokoll vermutlich gar nicht mehr nutzen will: Mark Shuttleworth kündigte 2010 in seinem Blog an, Ubuntu werde ab Version 12.04 mit Wayland anstatt mit X11 laufen [2]. Das gab dem ursprünglich als Hobbyprojekt deklarierten Wayland den nötigen Schub in der Entwicklung, um sich als Nachfolger von X11 zu empfehlen. Ursprünglich sollte Wayland eigentlich nur beweisen, dass sich X11 ohne allzu viel Aufwand umbauen lässt.

Später entschied sich Shuttleworth jedoch, einen eigenen Display-Server namens Mir zu entwickeln, anstatt Wayland zu unterstützen. Mir soll in Ubuntu 16.10 zusammen mit Unity 8 und dem Snappy-Paketformat einen der Pfeiler für die seit Langem angestrebte Konvergenz zwischen mobilen Geräten und PCs bilden [3]. Dieser erneute Alleingang von Canonical rief in der gesamten Linux-Community heftige Kritik hervor – vor allem, da die Ubuntu-Seite ihn mit nachweislich falschen Anschuldigungen gegen Wayland begründete. KDE-Entwickler Martin Gräßlin kündigte an, Mir in KWin nicht zu unterstützen, solange es lediglich bei Ubuntu zum Einsatz käme. Er nannte Mir “eine Lösung zu einem Problem, das es nie gegeben hat” [4].

Die meisten anderen Distributionen arbeiten mittlerweile am Umstieg auf Wayland; X11 wird uns jedoch generell noch einige Jahre begleiten. Um in der Umstiegsphase Probleme mit Anwendungen auszuschließen, die noch X11 benötigen, arbeitet in Form von Xwayland ein zusätzlicher, leicht modifizierter X-Server als Kompatibilitätsschicht im Hintergrund. Als erste Distribution plant Fedora, mit seiner Mitte Mai 2016 anstehenden 24. Ausgabe auf Wayland als Standard umzusteigen.

Wesentliche Unterschiede

Wayland unterscheidet sich konzeptionell und funktional in mehreren Punkten von X11. So fungiert es lediglich als Netzwerkprotokoll, der jeweilige Compositor stellt den eigentlichen Display-Server dar. Dagegen handelt es sich unter X11 beim Compositor um eine externe Komponente und somit um einen zusätzlichen Arbeitsschritt (Abbildung 3). Als Compositor bezeichnet man im Kontext von Wayland einen Display-Server, der das entsprechende Wayland-Protokoll implementiert. Beispiele dafür wären unter anderem die für Wayland erstellte Referenzimplementation Weston, Gnomes Display-Server Mutter und KWin bei KDE. Ein Blick auf die Handhabung eines Ereignisses wie eines Mausklicks macht die Unterschiede deutlich.

Abbildung 3: Der X-Server hat einen externen Compositor.

Bei X11 übermittelt der Kernel einen Mausklick über den Evdev-Treiber [5]. Der X-Server stellt fest, zu welchem Fenster das Ereignis gehört, und sendet es an den für das Fenster verantwortlichen Client weiter. Als problematisch erweist sich dabei, dass nicht etwa X die Position des Fensters kontrolliert, sondern der Compositor: Was zu tun ist, entscheidet also der Client. Da sich durch den Mausklick Elemente des Fensters ändern oder sich ein neues Fenster öffnet, sendet der Client eine Anforderung zum Rendern an den X-Server. Der X-Server wiederum leitet diese an den Grafiktreiber weiter, der seinerseits die Hardware mit dem Rendern beauftragt.

Der X-Server kalkuliert daraufhin die Geometrie und Lage der zu rendernden Fläche und sendet einen sogenannten Damage Event an den Compositor. Der entnimmt diesem Report, dass sich im Fenster etwas geändert hat und dass er einen Bereich des Displays neu zeichnen muss. Die Befehle dazu müssen nun erneut den X-Server durchlaufen. Der schleppt so reichlich Ballast mit, offeriert jedoch andererseits kaum Funktionen, die sich heute noch gebrauchen ließen. Er fungiert also nur noch als Mittelsmann, erzeugt dabei aber überflüssige Schritte zwischen Applikationen und dem Compositor sowie zwischen Compositor und der Grafikhardware.

Kurze Wege

Bei Wayland dient der Compositor auch gleich als Display-Server (Abbildung 4), dem der Kernel Ereignisse direkt übergibt. Wayland erlaubt es dem Compositor, diese ebenfalls direkt an die Clients zu übermitteln. Die resultierenden Damage Events wiederum senden die Clients direkt an den Compositor zurück (Abbildung 5).

Abbildung 4: Bei Wayland ist der Display-Server der Compositor.

Abbildung 5: Kurze Wege bei Wayland.

Der Compositor ermittelt nun, welchem Fenster das Ereignis gilt und welche Änderungen daran bereits vorgenommen wurden – Letzteres erkennt er anhand des Szenengraphen [6]. Das Ereignis leitet er direkt an die Clients weiter, die das Rendering selbst berechnen und danach die Aktualisierung des Fensters an den Compositor zurückmelden. Der zeichnet das Fenster neu und sendet einen Systemaufruf (ioctl) an das Kernel-Mode-Setting [7], um einen Pageflip anzufordern.

Dass die Clients das Rendern selbst übernehmen können, ermöglicht die Direct Rendering Infrastructure DRI [8], die Client und Server das Nutzen eines gemeinsamen Video-Pufferspeichers erlaubt. Bei Bedarf verlinkt der Client auf eine Rendering-Bibliothek wie OpenGL respektive Vulkan oder die Rendering-Engines von Qt oder GTK+, die dann direkt in den gemeinsamen Puffer schreiben.

Als einziger Nachteil von Wayland gegenüber X11 gilt das Fehlen der Netzwerkfähigkeiten. Allerdings gibt es mit dem Remote Desktop Protocol RDP sowie Virtual Network Computing (VNC) heute bessere Möglichkeiten, Desktops oder einzelne GUI-Anwendungen übers Netz zu schicken. Auch ein RDP- oder VNC-Server, der direkt auf Wayland aufsetzt, wäre denkbar.

Aus Sicherheitsaspekten kommt hier einer historisch bedingten Schwachstelle von X11 ohnehin weit mehr Gewicht zu: Da der X-Server direkt mit der Hardware korrespondiert, läuft er traditionell mit Root-Rechten. Das Kernel Mode Setting KMS macht diese Vorgehensweise zwar mittlerweile eigentlich überflüssig, kommt dazu aber bisher wenig zum Einsatz. Wayland dagegen benötigt grundsätzlich keine Root-Rechte, da es über den Kernel mit der Hardware kommuniziert.

Der Entwicklungsstand von Wayland

Wayland und Weston liegen inzwischen in Version 1.9 vor. Das Protokoll selbst gilt als ziemlich ausgereift, sodass die Entwickler derzeit keine neuen Funktionen mehr implementieren. Das verschafft den Programmierern der Compositoren von KDE, Gnome, Enlightenment, Sailfish OS oder Tizen die nötige Zeit, die Arbeit an ihren Wayland-Implementationen zu beenden und diese zu testen.

Der Referenz-Compositor Weston [9] dagegen bringt laufend neue experimentelle Technologien und Schnittstellen mit (Abbildung 6). Dazu zählt etwa das Atomic Kernel Mode Switching [10], mit dem sich völlig flackerfreie Darstellungswechsel realisieren lassen. Schon Weston 1.5 enthielt mit Libinput eine Bibliothek, die Eingabegeräte verschiedener Compositoren verwaltet und die damit Treiber wie evdev, synaptics oder wacom ersetzen soll. Fedora nutzt Libinput seit Version 22 zum Verwalten der Ein- und Ausgabegeräte (Abbildung 7).

Abbildung 6: Der Wayland-Compositor bedient verschiedene Clients.

Abbildung 7: Libinput kümmert sich um Ein- und Ausgabe-Events sowie die Geräte dahinter.

In Sachen Compositor zählt das Gnome-Projekt als am fortschrittlichsten: Fedora enthält bereits seit über einem Jahr experimentelle Unterstützung für Wayland. In der Standardinstallation von Fedora 23 bietet das System im Anmeldemanager die Möglichkeit an, eine Wayland-Sitzung zu starten. Fedoras Experimentierdistribution “Rawhide” geht sogar noch einen Schritt weiter und nutzt Wayland seit Kurzem als Standard. Hier muss der Anwender gegebenenfalls manuell die Datei /etc/gdm/custom.conf editieren, um noch eine herkömmliche X.org-Session zu erhalten. Da nicht jeder “Rawhide” testen möchte, versprechen die Entwickler, alle Wayland betreffenden Fehlerbereinigungen zeitnah auch in Fedora 23 einfließen zu lassen. Damit bleiben Anwender des Fedora-Desktops bei Systemaktualisierungen sehr nah am aktuellen Wayland-Entwicklungsstand.

Um Wayland mithilfe eines Live-Images von Fedora 23 zu testen, müssen Sie nach dem Start des Systems ein Passwort für den Live-User anlegen, sonst erscheint die Wayland-Option nicht im Anmeldemanager. Dazu klicken Sie in der rechten oberen Ecke des Desktops auf den abwärts gerichteten Pfeil und wählen Live System User | Account Settings. Dort tragen Sie dann das Passwort ein. Fedora legt Wert auf möglichst sichere Passwörter und erzwingt diese auch.

Danach wechseln Sie zu Live System User | Logout und gelangen so in den Anmeldemanager, wo Sie über das Zahnrad-Symbol links neben Anmelden die Wayland-Session wählen (Abbildung 8). Danach spielen Sie am besten direkt die neuesten Aktualisierungen ein. Das klappt am schnellsten mit dem Befehl sudo dnf upgrade in einem Terminal. Zur Kontrolle, ob wirklich eine Gnome-Wayland-Sitzung läuft, setzen Sie auf der Konsole das Kommando aus Listing 1 ab. Im Erfolgsfall zeigt es einen Socket auf /run/user/1000 an.

Abbildung 8: Eine Wayland-Sitzung im Gnome-Anmeldemanager GDM.

$ ls -l $XDG_RUNTIME_DIR/wayland-0
srwxr-xr-x. 1 liveuser 0 Dec 10 14:56 /run/user/1000/wayland-0

Einschränkungen

Derzeit gibt es beim Testen einer Wayland-Sitzung noch einige Einschränkungen. Zum einen müssen Sie freie Grafiktreiber zum Test nutzen, da weder AMD noch Nvidia auf Wayland angepasste Treibern liefern können. Wollen Sie Wayland in einer virtuellen Umgebung testen, fällt Virtualbox dazu aus, da dessen virtueller Grafiktreiber ebenfalls noch nicht mit Wayland zurechtkommt. Hier müssen sie zu KVM oder Vmware Player greifen. Des Weiteren fehlt noch die Implementation von gebräuchlichen Funktionen wie Copy & Paste per Maus sowie die Unterstützung für den Betrieb mehrerer Monitore. Zu guter Letzt wirkt es störend, dass der Mauszeiger oft erst nach einigen Sekunden reagiert.

Sämtliche Kernpakete von Gnome arbeiten bereits mit Wayland zusammen. Weitere Anwendungen wie etwa Firefox bedienen sich noch der Zwischenschicht Xwayland [11], die als Server unter dem Wayland-Protokoll läuft (Abbildung 9). Ein sichtbarer Unterschied zwischen nativer Wayland-Unterstützung und der Verwendung von Xwayland lässt sich nicht feststellen. Der Befehl xlsclients zeigt eine (nicht immer vollständige Liste) der Software, die noch Xwayland benötigt.

Abbildung 9: Xwayland läuft als modifizierter X-Server unter Wayland.

Fazit

Die Darstellung von Fenstern und Menüs gelingt Wayland inzwischen, anders als bei ersten Tests vor einem halben Jahr, sehr sauber und flackerfrei. Alle Fensterelemente erscheinen an den richtigen Stellen. Im Normalbetrieb läuft eine Wayland-Sitzung zwar stabil, doch kommen Abstürze hin und wieder vor. Hier springt dann in der Regel X11 ein, manchmal fällt man aber auch auf den Anmeldemanager zurück. Stören Sie solche kleinen Einschränkungen nicht, spricht ansonsten wenig gegen eine Dauernutzung von Wayland. Fehler im Zusammenhang mit Wayland melden Sie den Entwicklern am besten über den Bugzilla von Gnome [12].

Nach sieben Jahren Entwicklung befindet sich Wayland damit im Endspurt auf die Ziellinie, auch Plasma 5.5 harmoniert bereits mit ihm [13]. Angesichts fehlender proprietärer Treiber und noch bestehender Fehler erscheint trotzdem die Absicht des Fedora-Projekts, Wayland bereits im nächsten Release zum Standard zu machen, als ambitionierter Plan – im Mai 2016 wissen wir mehr. In jedem Fall begleitet uns der klassische X.org-Server unter Linux noch für einige Jahre, selbst wenn Wayland tatsächlich 2016 in einigen Distributionen als Standard einzieht.