© ladyligeia, 123RF

Das X-Window-System aus den 1980er Jahren bildet nach wie vor die Basis der grafischen Benutzeroberfläche unter Linux. Beim Umgang damit verzweifeln Entwickler aber an Altlasten und unzeitgemäßer Technologie. Mit Wayland und Mir streben nun gleich zwei vielversprechende Alternativen den Wachwechsel an.

Das gute alte X-Window-System besteht im Kern aus einem X-Server, der Ereignisse von Eingabegeräten entgegennimmt und die Grafiken auf den Bildschirm zeichnet. Hinzu kommt ein so genannter Compositor, zum Beispiel Compiz, der die Positionen der Fenster erfasst und sie gegebenenfalls mit einem lustigen Grafikeffekt versieht (Abbildung 1). Die Desktopumgebungen fügen zudem noch einen Windowmanager hinzu, der jedes Fenster unter anderem mit einem Rahmen dekoriert.

Abbildung 1: Der Kernel meldet einen Mausklick an den Server, der das Event an einen X-Client weiterleitet. Dieser stellt eine Renderanfrage an den X-Server, der auch den Compositor informiert. Letzterer setzt den Bildschirmbereich neu zusammen und bittet den X-Server, ihn neu zu zeichnen.

Alle diese Komponenten müssen zeitaufwändig miteinander kommunizieren. In der Vergangenheit haben zudem die X-Server-Entwickler immer wieder Funktionen ausgelagert. Schriften setzt heutzutage beispielsweise die Bibliothek Freetype, während die Bildschirmauflösung der Kernel via Kernel Mode Setting (KMS) einstellt. Gleichzeitig schleppt das X-Window-System (kurz X11) noch zahlreiche Altlasten mit sich herum, etwa eine eigene Zeichenbibliothek für einfache 2-D-Grafiken.

Bleibt alles anders

Den Programmierer Kristian Høgsberg störte neben diesem gewachsenen komplexen Aufbau auch die umständliche Arbeitsweise. Also entwarf er im Jahr 2008 kurzerhand eine Alternative, die er Wayland taufte [1]. Dabei beschränkte er sich auf die Kernfunktionen, die solch ein Displaysystem derzeit unter Linux leisten muss. Wayland wollte er zudem so sehen, dass geänderte Bildschirmbereiche bei der Anzeige nicht optisch zerreißen (Tearing), nicht verzögert auf dem Bildschirm landen (Lag), kein Flackern auftritt (Flicker) und der Server Inhalte nicht unnötig neu zeichnet [2].

Heraus kam ein erstaunlich schlankes und effizientes System. Neu daran ist vor allem, dass die Anwendungen ihre Fensterinhalte selbst zeichnen müssen – wahlweise zu Fuß, über Bibliotheken wie GTK+ oder Hardware-beschleunigte Schnittstellen wie Open GL. Medienberichte machten zunehmend Helfer auf Høgsbergs neue Displayserver-Architektur aufmerksam. Im Herbst 2010 kündigte Mark Shuttleworth, Gründer von Canonical und Ubuntu, in einem Blogpost an, dass die Distribution langfristig auf Wayland umsteigen wolle [3].

Einer für alles

Auf einem System mit Wayland läuft im Hintergrund der so genannte Wayland-Compositor. Klickt ein Anwender in ein Fenster, empfängt dieser ein entsprechendes Ereignis vom Kernel. Der Compositor prüft daraufhin, in welches Fenster der User geklickt hat. Das gelingt ihm schneller als dem X-Server: Im Gegensatz zu seinem Vorfahren weiß der Wayland-Compositor stets, wo sich welches Fenster befindet und welche Transformationen er auf das Fenster angewendet hat. Ist das passende Fenster ausgemacht, schickt der Compositor das Ereignis an die zugehörige Anwendung (Abbildung 2).

Abbildung 2: Im Gegensatz zum X-Window-System aus Abbildung 1 verschmelzen bei Wayland X-Server und Compositor zum Wayland-Compositor.

Solche unter Wayland laufenden Programme heißen Wayland-Clients. Diese wiederum zeichnen jetzt bei Bedarf ihre eigenen Fensterinhalte neu. Anschließend benachrichtigen sie den Compositor, der wiederum den Bildschirminhalt zusammenstellt und auch die Anzeige veranlasst.

Namenswirrwarr

Compositor und Clients reden über ein Netzwerkprotokoll miteinander, das den Namen Wayland trägt. In der Praxis bezeichnen Entwickler aber auch gern das komplette System aus Clients und Compositor lapidar als Wayland. Ihre Nachrichten tauschen die beiden über Unix-Sockets aus. Der Name des Endpunkts steckt in der Umgebungsvariablen »WAYLAND_DISPLAY« und lautet gewöhnlich »wayland-0«. Der Nachrichtenversand erfolgt stets asynchron, was wiederum die Arbeitsgeschwindigkeit erhöhen soll.

Um Programmierern die Arbeit an Clients und Compositor zu erleichtern, stellen die Wayland-Entwickler die C-Bibliotheken »libwayland-client« und »libwayland-server« bereit (Abbildung 3). Verwirrend: Diese Referenzimplementierung des Netzwerkprotokolls trägt ebenfalls den Namen Wayland. Den Quellcode der beiden Bibliotheken bietet die Projektseite im »wayland«-Paket an [1].

Abbildung 3: Compositor und Clients nutzen unter Wayland etablierte Bibliotheken beziehungsweise Kernel-Schnittstellen. Verwirrend: Die Referenzimplementierung des Netzwerkprotokolls heißt auch Wayland.

Zu seinem Inhalt gehört auch eine XML-Datei namens »wayland.xml«, die eine formale Definition der erlaubten Nachrichten und somit auch des Wayland-Protokolls enthält. Damit verarbeiten insbesondere Programme die Protokollspezifikation automatisch.

Diese Option nutzen auch die Wayland-Entwickler: Die beiden C-Bibliotheken erzeugt der zum Quellcode-Paket gehörende Wayland-Scanner (halb-)automatisch aus der XML-Datei. Wer die Bibliotheken nach Anleitung übersetzt, merkt davon nichts.

Selbstständig

Clients müssen ihre Fensterinhalte selbst zeichnen (englisch “rendern”). Dazu fordert der Client zunächst beim Compositor einen Speicherbereich an, auf den beide Parteien zugreifen können – einen so genannten Shared Memory Buffer (SMB). In ihm legt der Client den neuen Fensterinhalt ab. Dann teilt er dem Compositor mit, dass sich gerade etwas verändert hat, welcher rechteckige Bereich betroffen ist und in welchem Buffer der Fensterinhalt liegt. Daraufhin schnappt sich der Compositor den Buffer und arrangiert das darin abgelegte Bildmaterial zusammen mit den anderen Fenstern zu einem Gesamtkunstwerk.

Zwar muss der Client den Buffer beim Compositor anfordern, die Verwaltung des Buffers obliegt aber dem Client. Der kann für jede Zeichenoperation einen neuen Buffer nutzen oder mehrere Buffer im Voraus anfordern und dann zwischen diesen hin und her wechseln.

Die umständliche Arbeit mit den Buffern und der Bibliothek »libwayland-client« spart sich, wer seine Programme mit SDL, Clutter, Cairo, GTK+ 3 oder Qt 5 entwickelt. Diese bekannten Grafikbibliotheken respektive GUI-Frameworks unterstützten mittlerweile Wayland von Hause aus.

Im Fall von GTK+ 3 und Qt 5 dürfen sogar die späteren Anwender entscheiden, ob sie für die Anzeige X11 oder Wayland verwenden. GTK+ 3 bietet dazu die Umgebungsvariable »GDK_BACKEND«[4], bei Qt 5 heißt sie »QT_QPA_PLATFORM«. Zusätzlich kennen Qt-Programme noch den Kommandozeilen-Parameter »–platform«, um die Ausgabe auf einem der Systeme zu erzwingen.

Neben den genannten Möglichkeiten malt der Client seinen Fensterinhalt auch Hardware-beschleunigt via Open GL oder Open GL ES. Dazu reserviert der Client zunächst über die EGL-Schnittstelle einen Buffer direkt auf der Grafikkarte. EGL [5] stammt genau wie Open GL von der Khronos Group und vermittelt zwischen dem Fenstersystem – in diesem Fall Wayland – und den Grafikbibliotheken Open GL und Open GL ES.

Hat der Client mit einer der beiden seinen Fensterinhalt gezeichnet, übergibt er die Kontrolle an den Compositor. Der stellt seinerseits mit EGL, Open GL und Open GL ES den Bildschirminhalt zusammen. Zum Schluss weist der Compositor die Grafikkarte an, das Ergebnis anzuzeigen. Analog lässt sich auch der designierte Open-GL-Nachfolger Vulkan nutzen. Dort tritt an die Stelle von EGL das Window System Interface (WSI, [6])

Freiheit!

Wayland schreibt weder ein Rendering-Verfahren noch bestimmte Hardware vor. Folglich sind auch EGL und Open GL optional, obwohl die offizielle Dokumentation sie erwähnt [7]. Dies hat den Vorteil, dass sich die EGL-Implementierung jederzeit unabhängig von Wayland ändern oder austauschen lässt. Die Clients und der Compositor müssen sich nur auf eine Implementierung einigen. Zudem erlaubt es das System, weitere Grafikstacks anzubinden, wenn der Compositor den passenden Buffer(-Typ) anbietet. Denkbar wäre ein spezieller Buffer für Stereobilder, die dann auf einer VR-Brille landen. Das erfordert nicht einmal Änderungen am Wayland-Protokoll.

Diese Flexibilität hat jedoch auch Grenzen: So kooperiert ein Client nur dann mit einem Compositor, wenn dieser die gleiche EGL-Implementierung nutzt beziehungsweise ebenfalls einen solchen speziellen Buffer für Stereobilder anbietet. Erlaubt es der Compositor, kann die Hardware sogar direkt die Inhalte aus dem Buffer übernehmen und anzeigen. Das ist vor allem bei Spielen und Videos im Vollbildmodus nützlich.

Im Gespräch mit dem Linux-Magazin nennt Wayland-Entwickler Pekka Paalanen einen weiteren Punkt: “Das ultimative Ziel bei der Videowiedergabe wäre ein Hardware-Videodecoder, dessen erstellte Buffer Wayland an den Displayserver übergibt, der sie dann direkt ausgibt. Eine spezielle Rasterhardware kümmert sich dabei um das Skalieren und die Farbkonvertierung, ohne die GPU oder CPU einzubinden. Dies nennt man Zero Copy: Hat der Decoder ein Raw-Frame (gewöhnlich im YUV-Farbraum) produziert, gibt es keinen weiteren Verarbeitungsschritt, der das Bild in einen anderen Buffer kopiert oder transformiert. Dies ist insbesondere für eingebettete Systeme sehr wichtig, die hochauflösende Videos wiedergeben möchten, wofür ihnen andernfalls womöglich die nötige Speicherbandbreite fehlt.”

Des Weiteren muss der Wayland-Compositor nicht zwingend als eigenständiger Displayserver laufen, sondern kann auch selbst wieder als Wayland- oder X11-Client auftreten. In diesen Fällen reißt der Wayland-Compositor normalerweise ein Fenster auf, in dem dann die Ausgaben der Wayland-Clients erscheinen.

Analog dürfen Clients normale Anwendungen, X-Server oder ein anderer Wayland-Compositor sein. Genau dies macht sich X-Wayland zunutze: Dabei handelt es sich um einen X-Server, der als Client unter Wayland läuft. Dank seiner Hilfe lassen sich alte X11-Anwendungen unter Wayland weiterhin nutzen. Diese verbinden sich nach dem Start mit X-Wayland, das die Fensterinhalte seinerseits über Wayland auf den Bildschirm bringt.

Auf nach Weston

Mit Weston stellen die Wayland-Entwickler eine Referenzimplementierung des Wayland-Compositors bereit. Dieser steht wie die Client-Bibliotheken unter der MIT-Lizenz. Er dient zugleich als Vorbild für die Entwickler von Desktopumgebungen: Damit diese unter Wayland laufen, müssen sie ihre Fenstermanager zu einem kompletten Wayland-Compositor umarbeiten. Entsprechende Bemühungen treiben derzeit unter anderem das KDE- und das Gnome-Projekt voran. Die bislang erzielten Ergebnisse probieren Gnome-Anwender mit einem aktuellen Fedora aus (Abbildung 4).

Abbildung 4: Die meisten Distributionen mit Wayland-Support erlauben es, im Anmeldebildschirm auf eine Sitzung mit Wayland zu wechseln. Die Abbildung zeigt dies für Fedora 24.

Der Entwicklungsstand von Kwin aus Plasma 5 lässt sich vor allem mit dem Livesystem KDE Neon begutachten [8]. Dort rüstet der Befehl

sudo apt-get install plasma-workspace-wayland

zunächst Wayland nach. Der User wechselt dann im Login-Bildschirm links unten in der Ecke zu »Desktop Session: Plasma (Wayland)«. Schließlich gibt es mit Rebecca Black OS ein Livesystem, das komplett auf Wayland und Weston setzt und gleich mehrere Compositor-Ausführungen zum Probieren mitbringt (Abbildung 5, [9]).

Abbildung 5: Rebecca Black OS führt hier Weston aus, das Terminal ist eine native Wayland-Anwendung.

Beim alten X-Window-System zeichnet ein Fenstermanager Rahmen und weitere Dekorationen um die einzelnen Fenster. Die Wayland-Spezifikation schweigt sich hingegen über die Zuständigkeiten aus. Meist dekoriert der Compositor die Fenster mit Rahmen (Server Side Decoration). Nach diesem Prinzip arbeiten auch Mutter aus Gnome und Kwin aus Plasma 5.

Wahnsinnige Geschwindigkeit

Die derzeit existierenden Wayland-Compositor-Arten nutzen Kernel Mode Setting, um die Auflösung der Grafikkarte einzustellen, sowie EGL und Open GL (im Fall von Weston Open GL ES 2). Die letztgenannten Schnittstellen stellt die Grafikbibliothek Mesa 3D bereit, die wiederum den Direct Rendering Manager (DRM) des Kernels verwendet (Abbildung 3). Anfangs lief Wayland daher nur mit freien Grafikkarten-Treibern.

Seit Version 364.12 unterstützt auch der proprietäre Nvidia-Treiber Wayland. Der dabei verwendete Ansatz über sogenannte EGL-Streams setzte jedoch einen modifizierten Weston voraus, wobei Nvidia immerhin die passenden Patches bereitstellte. Die Wayland- und Weston-Entwickler lehnten diesen Ansatz jedoch ab. Auch KDE-Entwickler Martin Gräßlin schloss aus, Kwin anzupassen – zumindest so lange die Patches nicht auch Teil von Weston wären [10].

Die Nvidia-Entwickler suchten daraufhin das Gespräch mit den Wayland-Programmierern, wie der Finne Pekka Paalanen berichtet: “Die Konferenz XDC 2016 ist ein Wendepunkt in dieser Geschichte. Nvidia-Entwickler baten um Hilfe, um eine Lösung zu entwerfen, die für jeden funktioniert. Dafür ernteten sie bereits auf der Konferenz großen Zuspruch. Mittlerweile arbeiten verschiedene Personen an den technischen Details. Aber es ist ein sehr schwieriges Problem, dem man quasi ein Jahrzehnt lang ausgewichen ist, weil es als zu schwierig galt, es gut zu lösen.” Das Ergebnis dieser Zusammenarbeit ist ein neues API namens Unix Device Memory Allocator, dessen Entwicklung zurzeit allerdings noch am Anfang steht ([11], [12])

Derweil haben die Gnome-Entwickler ihren Compositor so modifiziert, dass er die proprietären Nvidia-Treiber unterstützt [13]. Das Ergebnis probieren die Anwender bereits in Fedora 25 Workstation aus. Die Änderungen am Compositor wollen die Entwickler aber zugunsten des gerade neu entstehenden API irgendwann wieder zurücknehmen. Auch der Referenz-Compositor Weston hat mittlerweile ausgewählte Nvidia-Patches integriert. Der Support für EGL-Streams fehlt hier explizit, die Entwickler warten lieber auf das neue API.

Hereinspaziert

Der Compositor muss die angeschlossenen Eingabegeräte überwachen und verwalten. Um Compositor-Herstellern die Arbeit zu erleichtern, lagerten die Weston-Entwickler den Code in eine separate Bibliothek aus. Die Libinput erkennt neu angeschlossene Eingabegeräte, empfängt von ihnen ausgesandte Events und reicht diese aufbereitet an den Compositor weiter. Dazu kommuniziert Libinput mit Udev und der Evdev-Schnittstelle im Kernel (Abbildung 3). Neben Mäusen und Tastaturen unterstützt Libinput auch Touchgeräte.

Beim X-Window-System kommunizieren Clients bei Bedarf über ein Netzwerk mit dem X-Server. Dadurch lassen sich Programme auf einem entfernten Rechner starten und ihre Fenster auf das lokale System holen. Das funktioniert für den Anwender transparent und sogar prinzipiell systemübergreifend. Diese Netzwerktransparenz fehlt Wayland. Zwar gab es immer wieder Versuche, Wayland entsprechend zu erweitern. Diese schafften es aber bislang nicht in die offizielle Spezifikation. Zu den gescheiterten Projekten zählt etwa Remote Wayland, das im Rahmen des Google Summer of Code 2011 entstand [14]. Auch das Gnome-Projekt führte eigene Versuche durch [15], eine Alternative bietet Fernwartungssoftware wie etwa VNC.

Warum die Einführung der Netzwerktransparenz so kompliziert ist, erläutert Pekka Paalanen ausführlich: “Das Wayland-Protokoll wurde mit Shared Memory im Hinterkopf geschrieben. Dank geteiltem Hauptspeicher sind die Kosten für die Datenübertragung effektiv bei null. Wegen dieser Optimierung fehlen ihm allerdings die Punkte, an denen sich Netzwerkübertragungen einhaken lassen. Man müsste viele Wayland-Nachrichten auswerten, bevor man erführe, wann und welche Teile eines Buffers zu übertragen sind, folglich würde ein simples Weiterleiten der einzelnen Nachrichten nicht funktionieren. Fängt man an, die notwendige Maschinerie zu bauen, die weiß, was und wann zu senden ist, erkennt man bald, dass man ein Viertel eines Compositors geschrieben hast. […] Aber Moment mal – man muss doch ziemlich viele Wayland-Nachrichten auswerten, um Inhalte über ein Netzwerk zu schicken … was sendet man da eigentlich über das Netzwerk? Das ist sicher nicht mehr 100-prozentig Wayland.

Anstatt also künstlich Netzwerktransparenz einzubauen und dadurch unnützen Overhead und Komplikationen zu erzeugen, die eine lokale Umgebung nicht braucht, beschränkt Wayland sein Betätigungsfeld auf die lokale Kommunikation und optimiert sie dafür. Indem Wayland diese beiden [den Netzwerk-Support und die lokale Kommunikation, d. Red.] voneinander trennt, dürfen die Übersetzungsschichten zwischen beiden so kompliziert, klug und vorausschauend sein, wie sie wollen.

Nicht zuletzt kann man ein bekanntes Remoting-Protokoll unterstützen, etwa RDP, und so verhindern, ein (schlechtes?) neues zu erfinden. Diese Design-Entscheidung weicht auch komplett der Frage aus, ob man einzelne Fenster oder den kompletten Desktop übertragen will. Es erlaubt interessante Anwendungsfälle, wie etwa dasselbe Fensters sowohl lokal als auch auf entfernten Bildschirmen anzuzeigen, wobei es möglicherweise sogar verschiedene Leute aus unterschiedlichen Ländern zugleich nutzen.”

Unendliche Weiten

Im Frühjahr 2013 kündigte Canonical überraschend an, einen eigenen Displayserver namens Mir zu entwickeln. Die bestehenden Lösungen würden schlichtweg nicht die Anforderungen des Unternehmens erfüllen [16]. Insbesondere suche Canonical einen Displayserver, der effizient auf Mobiltelefonen läuft und zudem mit den proprietären Android-Treibern zusammenarbeite. Nach der Inspektion des Wayland-Protokolls habe die Firma erkannt, dass die Spezifikation diese Anforderungen nicht erfülle.

Die im Internet verfügbare Dokumentation zu Mir ist äußerst dürftig. Sie beschränkt sich auf eine Handvoll Seiten im Ubuntu-Wiki [17], eine Launchpad-Seite mit dem Quellcode [18] sowie einige wenige Blogposts der Mir-Entwickler. Demnach soll Mir alle Geräte unterstützen, auf denen auch Ubuntu läuft: Angefangen beim Desktop, über Mobilgeräte und eingebettete Systeme bis hin zu Kiosksystemen.

Mir soll zudem effizient arbeiten, schonend mit CPU und Speicher umgehen, ein stabiles API bieten sowie gut getestet sein. Die Entwickler legen darüber hinaus großen Wert auf die Sicherheit, wie Canonicals System Architect Thomas Voß dem Linux-Magazin versichert: “Reale und virtuelle Input-Streams sind darauf ausgelegt, nur die fokussierte Applikation zu erreichen. Falls die Input-Streams durch eine weitere Komponente gefiltert/verarbeitet werden muss, so muss entweder das System oder der User diese Komponente als vertrauenswürdig einstufen. Ein weiteres interessantes Beispiel ist hier Copy & Paste. Unter Mir mit Unity 8 ist es nicht vorgesehen, dass ,unberechtigte’ Applikationen den Inhalt des Paste-Buffers ,ausspähen’.”

Die im Ubuntu-Wiki skizzierte Architektur von Mir ähnelt Wayland und verwendet einige seiner Konzepte. So nutzt Mir ebenfalls EGL und bietet mit X-Mir einen X-Server an, der alte X11-Programme ausführt. Umgekehrt lässt sich Mir auch unter einem X-Window-System starten. Die Eingabegeräte hat Mir zunächst über den Android Inputstack verwaltet. Diesen passten die Canonical-Mitarbeiter so an, dass er sich auch ohne den Android-Quellcode übersetzen ließ.

Ende 2015 stieg Mir mit der Version 0.18 jedoch auf die Bibliothek Libinput um – die ironischerweise aus dem Wayland-Projekt stammt [19]. Laut Ubuntu-Wiki hatte sich Canonical unter anderem aufgrund des unflexiblen Input-Event-Handling gegen Wayland entschieden.

Frische Muscheln

Auch bei Mir gibt es einen so genannten Compositor. Er arrangiert aus allen Fenstern die komplette Darstellung und malt das Resultat anschließend auf den Bildschirm. Die einzelnen Fenster bezeichnet Mir dabei als Surfaces. Der Compositor besitzt zudem einen Renderer, der auf die einzelnen Surfaces noch Effekte anwendet. Der Compositor synchronisiert sich mit der Wiederholfrequenz des Bildschirms (Vblank), um so möglichst Tearing-Effekte und unnötige (Render-)Zyklen zu vermeiden.

Gegenüber Wayland kennt Mir das Konzept Trusted Sessions. Mit ihnen stellen vertrauenswürdige Komponenten Rückfragen an den Nutzer, die dann wiederum im Fenster (Surface) der Anwendung erscheinen. Möchte etwa eine Anwendung auf Positions- oder Standortdaten zugreifen, bittet der zugehörige Dienst den Anwender um Erlaubnis. Die Rückfrage zeigt Mir dann im Surface an.

Um die Fensterverwaltung kümmert sich bei Mir mit der Shell eine zusätzliche Komponente. Sie stellt zudem mehrere Komfortfunktionen bereit, etwa einen Anwendungsstarter und einen Alt-Tab-Switcher. Unter Ubuntu dient Unity 8 als Shell (Abbildung 6), weitere existierten zu Redaktionsschluss noch nicht.

Abbildung 6: Unity 8 kennt mit den so genannten Scopes spezielle Seiten, die Informationen zu einem bestimmten Thema anbieten. Die Desktop-Fassung stellt Scopes im gleichnamigen Fenster dar.

Mir erzwingt dabei eine konsistente Benutzerinteraktion, schreibt Thomas Voß: “Wichtig ist uns, dass Shells fundamentale Prinzipien des Window-Managements nicht verändern können. Das heißt, grundlegende Benutzerinteraktionen und Paradigmen werden von Mir eindeutig definiert. Natürlich ist es Shells auch weiterhin möglich, die grafische Darstellung ihren Bedürfnissen anzupassen. Wir möchten damit sicherstellen, dass sich Nutzer auf einen kleinsten gemeinsamen Nenner hinsichtlich der Interaktionen im Rahmen des Window-Managements einstellen können, unabhängig von der konkreten Shell.”

Die Mir-Entwickler stellen derzeit auf Launchpad zwei Bibliotheken bereit: »libmirserver« und »libmirclient«. Erstgenannte kapselt die Serverkomponenten von Mir und erlaubt es so, einen Compositor zu entwickeln. Die Bibliothek »libmirclient« nutzen Mir-Clients, um mit dem Mir-Server zu kommunizieren. Alternativ verwenden die Anwendungen auch die Toolkits SDL, GTK+ 3 und Qt 5, die Mir von Haus aus unterstützen. Qt und QML bilden auch die Basis für das Ubuntu SDK, mit dem Entwickler Ubuntu-Anwendungen schreiben [20].

Probefahrt

In der Praxis läuft Mir derzeit nur auf Smartphones mit Ubuntu Touch (Abbildung 7). Langfristig soll es zudem das X-Window-System in Ubuntu ablösen. Viele offizielle Ubuntu-Derivate wollen jedoch nicht mitziehen: Die Entwickler von Kubuntu und Ubuntu Gnome kündigten bereits an, künftig auf Wayland auszuweichen [21].

Abbildung 7: Auf Smartphones mit Ubuntu Touch werkelt im Hintergrund bereits Mir.

Nutzer von Ubuntu 16.10 dürfen erstmals Mir und Unity 8 testen (Abbildung 6). Das Duo hinterlässt jedoch einen äußerst unfertigen Eindruck: So beschränken sich die an Mir angepassten vorinstallierten Anwendungen auf einen simplen Browser und ein Terminal. X11-Anwendungen starteten zumindest auf dem Testsystem der Redaktion nicht. Die Pläne sehen vor, dass Ubuntu im Frühjahr 2018 komplett von X11 auf Unity 8 und Mir wechselt. Auf Smartphones läuft Mir mit Ubuntu Touch schon jetzt flüssig und stabil. Mir steht zudem im neuen Paketformat Snap für Ubuntu Core ab Version 16.04 bereit [22].

Genau wie Wayland nutzt Mir das Generic Buffer Management (GBM) aus Mesa 3D sowie DRM und KMS im Linux-Kernel. Es ist daher – zumindest im Moment – auch auf den freien Grafikstack angewiesen. Laut System Architect Thomas Voß arbeitet das Mir-Team zusammen mit Nvidia an einer neuen, an Mir angepassten Alphaversion des proprietären Nvidia-Treibers. Unter dem Intel-Treiber läuft Mir bereits. Daneben bereiten die Entwickler Mir auf verschiedene Backends vor. Insbesondere soll es künftig den Open-GL-Nachfolger Vulkan nutzen. Zudem denken sie an IoT-Geräte, auf denen das Rendern in Software erfolgen muss.

Mir steht unter der GPLv3, wer aber Verbesserungen einreichen möchte, muss Canonicals Contributor License Agreement (CLA) unterzeichnen. Core-OS-Entwickler Matthew Garrett kritisiert, dass Canonical den von Freiwilligen geschriebenen Code so kommerziell vertreiben kann – etwa an Hersteller von Smartphones [23].

Resümee

In der Vergangenheit gab es immer wieder Versuche, das betagte X-Window-System abzulösen, etwa Y [24] oder Fresco [25]. Die Chancen für Wayland stehen jedoch gut. So erhält der designierte X11-Nachfolger breite Unterstützung durch Branchengrößen wie Intel, Red Hat, aber auch Projekte wie Gnome und KDE. Sogar Nvidia geht auf die Wayland-Entwickler zu. Der bisherige Entwicklungsstand wirkt vielversprechend, unter Fedora und KDE Neon ist Wayland bereits relativ gut nutzbar. Der größte Nachteil von Wayland besteht allerdings in der fehlenden Netzwerktransparenz.

Mit dieser kann aber auch Konkurrent Mir nicht aufwarten. Er hat zwar seine Alltagstauglichkeit auf Smartphones unter Beweis gestellt, auf dem Desktop ist er jedoch noch nicht angekommen. Offenbar rächt sich hier, dass Canonical den Displayserver samt Desktopumgebung Unity 8 weitgehend im Alleingang entwickelt. Da sich sogar wichtige Ubuntu-Derivate für Wayland aussprechen, dürfte Mir zumindest vorerst eine Insellösung bleiben.