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 Umstellung der KDE Plasma Workspaces
){kind=small}
Martin Gräßlin
Wayland-Clients unter einem X11-Compositor
- Unterstützung von Wayland-Clients unter X11
- Wayland-Clients unter Wayland
- X11-Clients unter Wayland
Aktuell arbeiten die Entwickler an der ersten Phase. Der Compositor und Fenstermanager KWin wurde um erste Wayland-Unterstützung erweitert. Der Compositor kann im OpenGL ES 2.0/EGL-Backend Wayland-Clients verwalten und in den Scenegraph integrieren. Jedoch hat jeder Wayland-Client noch eine X11-Abhängigkeit. Jeder Client muss mit einer X11-Fensterdekoration versehen werden, um Eingabeereignisse im Compositor abfangen zu können (zur Erinnerung: X11 bietet keine Input Redirection) und an den Client weiterzuleiten.
){kind=small}
Martin Gräßlin
Wayland-Fenster (Zahnräder) wie ein normales X11-Fenster in den Compositor integriert
Aber nicht nur der Compositor muss Unterstützung erhalten. Auch der Plasma-Desktop muss initialen Support erhalten, um z.B. Wayland-Clients im Tasks-Applet anzeigen zu können. Viele dieser Funktionen sind X11-spezifisch und müssen nun in generische Funktionen umgewandelt werden: die X11-Funktionalität muss in ein Backend ausgelagert werden.
Hierbei ist es wichtig zu wissen, dass im Gegensatz zu den KDE-Anwendungen (welche auch auf Microsoft Windows und Mac OS X portiert sind) der Workspace nie dazu vorgesehen war, unter einem anderen Fenstersystem als X11 zu funktionieren. Dank einer guten Abstraktionsschicht ist es jedoch gelungen, den Plasma-Desktop auch auf Microsoft Windows zu portieren, und die ersten Ergebnisse der KWin-Portierung zeigen, dass auch dieses Projekt machbar ist. Hierbei wird das Verwalten der Fenster abstrahiert und die eigentliche Interaktion mit den Fenstern in Fenstersystem-spezifische Backends verlagert, ähnlich der bereits verwendeten Backend-Architektur im Compositing-Bereich (KWin unterstützt XRender, OpenGL 1.x/GLX, OpenGL 2.x/GLX und OpenGL ES 2.0/EGL als Backends).
Bei der zweiten Phase geht es darum, einen Workspace ohne X11-Laufzeitabhängigkeit zu erstellen. Dieser würde dann ausschließlich Wayland-Clients verwalten können. Dieser Entwicklungsschritt baut teilweise auf der ersten Phase auf. Voraussetzung hierfür ist, dass Wayland-Fenster bereits verwaltet und gezeichnet werden können. Nun ist es erforderlich, direkt auf der Hardware zum Rendern aufzusetzen und Input-Ereignisse weiterzuleiten, ohne den X-Server dazwischen zu haben.
Die Entwicklung der Phase 1 und 2 werden teilweise parallel erfolgen können. Auch hier hat bereits die Arbeit begonnen: mit Hilfe eines Google Summer of Code-Projekts wird der KWin-Quellcode abstrahiert und die X11-Interaktion in ein Backend verlagert mit dem Ziel, Wayland-Clients ohne X11-Abhängigkeit zu verwalten.
){kind=small}
Martin Gräßlin
X-Server unter einem Wayland-Compositor
Ziel der gesamten Entwicklung ist es, dass der Anwender niemals weiß, ob er unter X11 oder Wayland arbeitet und ob ein Fenster nun ein X11- oder Wayland-Fenster ist. Von der Benutzung her sollen sich die Systeme nicht unterscheiden. Erst nach Abschluss der zweiten Phase kann man beginnen, neue, nur Wayland-spezifische, Erweiterungen einzubauen.
Ausblick
An dieser Stelle ist es nun angebracht, einen Ausblick zu liefern, wann die Anwender mit Wayland arbeiten werden können. Dies ist natürlich sehr schwierig. Wayland ist immer noch eine sehr junge Technologie und mögliche Probleme, welche die Entwicklung behindern könnten, sind noch nicht abzusehen.
Grundsätzlich plant die KDE-Plasma-Community, wie am Desktop Summit in Berlin vorgestellt, im Winterrelease 2012 die Phase eins bereits als Entwicklervorschau zu integrieren. Das Ziel ist es, Anwendungs- und Workspaceentwicklern etwas in die Hand zu geben, um ihre Anwendung unter Wayland zu testen. Natürlich ist das auch für interessierte Anwender eine Option, um sich früh mit den neuen Möglichkeiten vertraut zu machen, jedoch wird vom produktiven Einsatz von Wayland-Clients zu diesem frühen Zeitpunkt abgeraten und die Entwickler werden noch keine Bugreports dafür annehmen.
Die zweite Ausbaustufe wird parallel gestartet und zielt auf die KDE Plasma Active Initative. Hierzu hatten die Entwickler bei ihrem Tokamak V Sprint bereits Ende April sich als Ziel gesetzt, das zweite Release auf Wayland aufzubauen. Als mobile Plattform ist genauso wie für MeeGo der Verlust von, unter X11 bekannter, Funktionalität kein Problem und dieser Formfaktor profitiert am meisten durch ein Ausschalten des X-Servers.
Somit wird nach aktueller Planung das Sommerrelease 2012 es ermöglichen, einen X-freien Workspace zu betreiben. Jedoch wird dieser auf dem Desktop kaum einsetzbar sein, da noch zu viel fehlen wird. Wie lange es tatsächlich dauern wird, bis ein komplett einsetzbarer Wayland-Desktop zur Verfügung steht, ist aktuell noch nicht absehbar.
Autoreninformation
Martin Gräßlin arbeitet als KWin-Maintainer aktiv an der Portierung von KWin nach Wayland und hielt auf dem Desktop Summit 2011 einen Vortrag zu diesem Thema.
Dieser Artikel ist in freiesMagazin 08/2011 erschienen. Veröffentlichung mit freundlicher Genehmigung.
