Compositing nach X11
KDE Plasma auf dem Weg nach Wayland
Wayland gilt als möglicher Nachfolger der X11-Architektur. Die ersten Projekte, wie z.B. MeeGo, planen Veröffentlichungen mit Wayland und auch die großen traditionellen Desktopumgebungen planen die Unterstützung dieser neuen Architektur. In diesem Artikel wird die Transition auf Wayland am Fallbeispiel der KDE Plasma Workspaces betrachtet. Der Inhalt dieses Artikels wurde auch am diesjährigen Desktop Summit in Berlin als Präsentation vorgestellt.
Die X11-Architektur
In freiesMagazin 03/2011 wurde bereits die Architektur von X11 beleuchtet und warum es für die Zukunft nur die Lösung eines X-freien Systems geben kann. X11 ist eine Technologie aus den 80er Jahren des letzten Jahrhunderts, lange bevor irgend jemand an Anwendungsfälle wie Compositing gedacht hat.
In einer modernen X11-Architektur, wie sie heute von allen Desktopumgebungen verwendet wird (siehe Skizze rechts), ist die Funktionalität des X-Servers auf die eines Proxys beschränkt. Der X-Server ist nicht mehr für das Zeichnen der Fenster zuständig. Dies wird komplett vom Compositor und Fenstermanager (z.B. KWin) übernommen. In der X11-Architektur kann der Compositor nicht direkt mit den X-Clients (den Fenstern) sprechen – alle Informationen werden durch den X-Server geleitet.
){kind=small}
Martin Gräßlin
Moderne X11-Architektur: X-Server als Proxy zwischen Compositor und Fenstern
Diese Architektur schränkt die Möglichkeiten stark ein und erschwert die korrekte Implementierung. So werden zum Beispiel Maus- und Tastaturereignisse nicht durch den Compositor geleitet. Diese als »Input Redirection« bekannte Funktionalität wäre aber sinnvoll, denn eigentlich entscheidet der Compositor, welches Fenster die Ereignisse erhalten soll. Insbesondere sind interaktive, transformierte Umgebungen dadurch nicht möglich. Man denke dabei an so triviale Anwendungsfälle wie einen Anwendungsstarter in einer Übersicht der virtuellen Desktops oder einem auf Lagesensor reagierenden Invertieren des Bildes bei einem Tablet (Beispiel-Video: http://www.youtube.com/watch?v=BrK4c7iFJLs).
Generell entsteht ein Problem dadurch, dass der X-Server aus historischen Gründen noch für viele Funktionen verantwortlich ist, die eigentlich in den Compositor gehören. So pflegt der X-Server eine eigene »Stacking Order« (Anordnung der Fenster), obwohl alleine der Compositor über diese entscheidet. Der Compositor wäre eigentlich dafür verantwortlich, Richtlinien umzusetzen (z.B. Anordnung der Fenster, welches Fenster ist aktiv), kann dieses aber nicht, da die Funktion in X implementiert ist und jeder Client manuell den Zustand ändern kann. Dadurch entsteht ein dauernder Kampf zwischen Fenstermanager und Fenster, wie das Fenster aussehen soll.
Die Wayland-Architektur
In der Wayland-Architektur ist der Proxy zwischen Anwendungen und Compositor entfernt. Der Compositor sitzt direkt auf der Hardware und nutzt diese zum Zeichnen und zum Empfangen von Eingabeereignissen. Es ist die Aufgabe des Compositors, die Eingabeereignisse an die Wayland-Clients (Fenster) weiterzuleiten. Die in der alten Architektur fehlende Input Redirection ist nun ein direkter Bestandteil der Architektur.
){kind=small}
Martin Gräßlin
Mit Wayland wandert der Compositor in das Zentrum
Die Verbindung zwischen Clients und Compositor ist auch denkbar einfach gehalten. Zur Kommunikation wird ein Unix-Socket verwendet und über diesen Socket werden Bufferinformationen ausgetauscht. Die Clients zeichnen in einen Buffer und informieren den Compositor über Änderungen zum vorhergehenden Buffer (Frame/Bild). Der Compositor wiederum informiert den Client, wenn ein Frame gezeichnet wurde, sodass Compositor und Clients synchron zeichnen können.
Ansonsten ist die Interaktion zwischen Clients und Compositor (noch) sehr gering. Es existiert noch kein Fenstermanagement-Protokoll und es ist fraglich, ob es jemals eines geben wird. Mit Wayland sind die Richtlinien zum Verwalten der Fenster komplett in den Compositor verlagert, wodurch vieles, was X11 ermöglichte, einfach überflüssig wird. Als Beispiel kann man den Zustand »minimiert« verwenden: für den Client ist es eigentlich egal, ob er minimiert ist, die einzige wichtige Information ist, wann er zuletzt gezeichnet wurde, was er sowieso erhält.
Wayland Entwicklungsstand
Aktuell ist die Entwicklung noch nicht so weit fortgeschritten, dass man an einen produktiven Einsatz auf einem Desktop denken kann. Vieles ist noch nicht spezifiziert oder noch nicht implementiert. Kaum ein aktuell verfügbares Toolkit unterstützt bereits Wayland. Die wichtigen Komponenten wie Unterstützung in den Grafikkartentreibern haben erst mit Mesa 7.11 (Release erfolgte im Juli) Einzug gehalten. Ohne diese ist der Einsatz unter Wayland noch undenkbar. Unterstützung in Qt wird ab Version 4.8 verfügbar sein, dies erfordert aber auch, dass Distributionen Wayland standardmäßig paketieren (was bisher noch nicht der Fall ist).
Im aktuellen Entwicklungsstand muss eine Anwendung über OpenGL ES 2.0 zeichnen; »normales« OpenGL ist noch nicht vorgesehen, da dieses eine neue Schnittstelle ähnlich GLX benötigen würde. Der Einsatz von GLX wird allgemein abgelehnt, da dies wieder eine X-Abhängigkeit mit sich bringen würde. Dies bedeutet natürlich einen erheblichen Verlust an Funktionalität und reine OpenGL Anwendungen können nicht trivial einfach auf Wayland portiert werden.
Erschwerend kommt hinzu, dass bisher nur die freien Treiber das Projekt Wayland in Angriff genommen haben. Ob z.B. NVIDIA daran arbeitet, Wayland zu unterstützen, ist bisher nicht bekannt. Nouveau ist leider kein allgemein einsetzbarer Ersatz für den proprietären Treiber. Man denke hier an Anwendungsfälle wie garantierte Abwärtskompatibilität, Energieverwaltung, die Programmierschnittstelle CUDA und patentierte Technologien, die nur im proprietären Treiber verfügbar sind.
Die für die Zukunft angedachte Möglichkeit, einen X-Server unter Wayland zu betreiben, existiert auch nur in Gedanken. Ein kompletter Wechsel auf Wayland ist daher aktuell nur möglich, wenn man in Kauf nimmt, dass keine X-Anwendung mehr funktioniert. Dies ist ein akzeptabler Preis für mobile Einsatzgebiete wie MeeGo oder KDE Plasma Active.
