Wege im Grafik-Stack

Inhaltsverzeichnis

Ubuntus Mäzen Mark Shuttleworth hat mit der Ankündigung, in Zukunft Wayland auf dem Linux Desktop einsetzen zu wollen, das Freizeitprojekt des Open-Source-Entwicklers Kristian Høgsberg über Nacht in den Mittelpunkt des Interesses gerückt. Wayland unterscheidet sich vom klassischen X-Server, was Konsequenzen für den Grafik-Stack unter Linux haben dürfte.

Der Open-Source-Grafik-Stack hat in den letzten Jahren eine Menge Änderungen erfahren. Die benötigten Komponenten sind heute stärker modularisiert und in unabhängigere Funktionsgruppen unterteilt. Sie lassen sich dadurch wesentlich leichter neu kombiniert verwenden. Wayland ist gewissermaßen eine naheliegende Fortführung dieser Entwicklung. Um zu verstehen, wie die großteils vorhandenen Komponenten neu zusammenspielen, zuerst eine Beschreibung der klassischen und der heutigen X-Server-Architektur.

Eine wesentliche Rolle spielt dabei die Funktionsweise der aktuellen Open-Source-Treiber für das sogenannte Direct Rendering OpenGL. Basierend darauf lassen sich die Minimalanforderungen an ein Display-System ableiten, die Wayland implementiert (siehe „Onlinequellen“ [a]). Daraus wird auch klar, welche Komponenten für einen vollständigen grafischen Linux-Desktop noch fehlen. Auch Netzwerktransparenz oder Betriebssystemvirtualisierung finden in diesem Modell ihren Platz.

X11– Der Weg zum Bildschirm

Zentrale Komponente im bisherigen Treiber-Stack ist der X-Server. Wie Abbildung 1 zeigt, hat er im klassischen Treibermodell als einziger Beteiligter Zugriff auf die Grafikhardware. Der X-Server sorgt über den X-Grafiktreiber für ein korrektes Setup der Grafikkarte, angefangen vom Aufsetzen der PCIe-Schnittstelle, inklusive des Memory Mapping der Ressourcen der Grafikkarte, über das Initialisieren der Display-Ausgänge und das Erkennen und Ansteuern der angeschlossenen Monitore bis zum Zeichnen von Grafikprimitiven für die visuelle Darstellung.

Eine grafische Anwendung verbindet sich via Netzwerk-Socket mit dem X-Server. Über diesen empfängt die jeweilige Applikation Events von den Eingabegeräten und interagiert mit dem Window-Manager. Grafische Elemente lässt die Applikation vom X-Server auf die Grafikhardware zeichnen. Die Kommandos dazu fließen ebenfalls über die gleiche Netzverbindung. Mit dieser einfachen Architektur erhält man sofort die Netzwerktransparenz einer X11-Applikation.

In diesem klassischen Setup ist der X-Server die einzige Komponente, die die exakten Ressourcen auf der Grafikhardware kennt und verwendet. Selbst der Linux-Kernel, der den Status des X-Servers durch direkte Zugriffe auf die Grafikhardware leicht stören könnte, hält sich vornehm zurück, bis der X-Server seine virtuelle Konsole wieder freigibt.

Ähnliches gilt für die klassischen Eingabegerätetreiber im X-Server. Auch wenn das Aufsetzen der Kommunikation zu einer seriellen Maus weit weniger Auswirkungen auf das Gesamtsystem hat als eine aus dem Userspace am Kernel vorbei verwaltete PCI Ressource, gilt hier dasselbe Prinzip. Der X-Server ist der einzige Prozess/Treiber, der mit der Hardware kommuniziert. Er übernimmt, solange seine virtuelle Konsole aktiv ist, die volle Kontrolle über dieses Stück Hardware.

Ein Hauch Modernität

Bekanntheit erlangte das für viele visuelle Effekte auf dem Linux-Desktop verantwortliche sogenannte Compositing in der Anfangszeit mit den „Wobbling Windows“ und dem seinerzeit gern gezeigten „Desktop Cube“. So funktionieren die stufenlos verkleinerten Fenstervorschaubilder oder echte Fenstertransparenz erst seit Einführung der Composite Extension.

Technisch realisiert der X-Server dies, indem die Applikationen nicht mehr direkt in ihren nicht überdeckten Teil des Framebuffer rendern, sondern in einen für jedes Fenster separaten Puffer im Grafikspeicherbereich. Ein weiterer Prozess, der Composition Manager, kümmert sich dann um das finale Bild auf dem Bildschirm, in dem dieser die Einzelbilder der Applikationen zusammensetzt. Wichtigstes Hilfsmittel ist dabei, das Fensterbild an eine OpenGL-Textur zu binden und somit beliebige 3D-Geometrien texturiert zeichnen zu können. Transparente Fenster sind dann durch geeignetes Blending einfacher texturierter Rechtecke GPU-beschleunigt realisierbar.

Durch diese Architektur drängt sich aber eine dritte Applikation in den Weg der Grafikelemente von der Applikation auf den Bildschirm. Je nach Implementierung sind dadurch mindestens zwei weitere Prozess-Kontext-Switches notwendig, um das Bild auf den Schirm zu bringen.

Altlasten aus der X11-Gründerzeit

Häufiger Kritikpunkt an X11 ist das Kernprotokoll, das heute zu Teilen völlig ungenutzt ist, aber trotzdem gemäß Standard zur Verfügung stehen muss. So hat beispielsweise das Antialiasing-taugliche, clientseitige Font-Rendering das alte serverseitige Fontsystem heute schon größtenteils verdrängt. Trotzdem muss jede X11-Implementierung den vollen Satz der heute ungenutzten Font-Rendering-Funktionen zur Verfügung stellen.

Ebenfalls ungenutzt bleiben heute die meisten der im X11-Kernprotokoll definierten Zeichenoperationen. So spielt heute das Zeichnen einer ausgefüllte Ellipse für keines der GUI-Toolkits mehr eine Rolle.

Hier ist noch die Rückwärtskompatibilität zu einigen Applikationen, die noch immer darauf aufsetzen, oder umgekehrt die Möglichkeit, auf einigen der alten Unix-Maschinen auch aktuelle Applikationen noch netzwerktransparent darstellen zu können, ein gutes Argument, diese alten Zöpfe nicht abzuschneiden.

So weit der Blick zurück auf das klassische Treibermodell des X-Servers. Im Folgenden geht es um die Änderungen, die die Grundlage für Wayland bilden.

Den vollständigen Artikel finden Sie in iX 3/2011, erhältlich im Zeitschriftenhandel oder in Deutschland versandkostenfrei hier . (avr)