Aus LinuxUser 02/2016

Der X.org-Nachfolger Wayland im Praxiseinsatz

© Kennerth Kullman, 123RF

Fensterwechsel

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.
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.
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.
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 4: Bei Wayland ist der Display-Server der Compositor.
Abbildung 5: Kurze Wege bei Wayland.
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.

LinuxUser 02/2016 KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS
Deutschland

Hinterlasse einen Kommentar

  E-Mail Benachrichtigung  
Benachrichtige mich zu: