Xegl

Xegl ist ein Display-Server-Protokoll, welches über X11-Protokoll mit seinen Klienten kommuniziert. Ein Fenstermanager wird zusätzlich benötigt.

Xegl ist ein X-Display-Server-Protokoll für das Linux-Betriebssystem, mit dem eine Bereinigung und Modernisierung der aktuellen Linux-Grafiktreiberarchitektur erreicht werden soll. Basis ist die betriebs- und windowing-systemunabhängige Programmierschnittstellenspezifikation EGL. Xegl ist die Linux-spezifische Implementierung dieser Schnittstelle.

Anstelle – wie die bisherige X11-Architektur unter Linux – einen in den X-Server integrierten Hardwaretreiber zu verwenden, setzt Xegl auf eine Kombination aus einem Treiber für das Linux Framebuffer Device (fbdev), eine vom X Window System unabhängige Variante der Mesa 3D OpenGL-Bibliothek mit Hardwarebeschleunigung über das Direct Rendering Infrastructure Kernel-Interface, und der zusätzlichen 2D-Grafikbibliothek Cairo.

Die Entwicklung von Xegl wurde vor mehreren Jahren eingestellt und die gewünschte Funktionalität wurde weitgehend auf anderen Wegen umgesetzt.

Motivation

Ausgangssituation

Bisher gab es unter Linux standardmäßig zwei parallele Grafiktreiberarchitekturen: fbdev und XFree. Hinzu kommt die DRI-Schnittstelle für hardwarebeschleunigte Grafikoperationen, die aber bislang nur in Verbindung mit den X11-Treibern einsetzbar war.

X11/XFree

X11 (oder kurz X) ist ursprünglich eine Sammlung von Spezifikationen eines „Windowing Systems“, mit der Motivation, eine hardware- und systemunabhängige Plattform aus Protokollen und Schnittstellen für grafische Benutzeroberflächen zu definieren. Zur Definition dieser Plattform gehört ursprünglich daher nicht die Spezifikation von Grafikhardware-Treibern, die in einem entsprechenden Schichtenmodell korrekterweise unterhalb der Definition der Protokolle für die grafische Benutzeroberfläche anzusiedeln wären. Viele X11-Implementierungen für andere Unix-artige Betriebssysteme als Linux sind nach solch einem Schichtenmodell aufgebaut, z. B. gibt es unter Sun Solaris ein Framebuffer Device, das den Hardwaretreiber darstellt, und einen X-Server, der als Anwendung oberhalb dieses Treibers die Dienste des X11-Protokolls anbietet.

Das XFree86-Project, von dem die ursprüngliche X11-Implementierung für Linux entwickelt wurde, entschied jedoch seinerzeit, das Windowing-System direkt mit der Entwicklung von Hardwaretreibern zu verknüpfen. Dies war in einer Zeit, als kaum leistungsfähige Grafiktreiber für Linux existierten, ein Ansatz, um die Unterstützung von Grafikkarten gemeinsam mit der Entwicklung des Windowing-Systems voranzutreiben. Ein weiteres Ziel war die gemeinsame Entwicklung des Windowing-Systems für Linux und andere UNIX-artige Betriebssysteme auf PC-Hardware, z. B. FreeBSD. Hierzu wurde eine Treiberarchitektur entwickelt, die zwar hardwareabhängig (ist bei Hardwaretreibern per definitionem gegeben), aber betriebssystemunabhängig war. Unter diesen Voraussetzungen führte XFree sein eigenes Treibermodell ein, das bis heute unter Linux Stand der Technik ist.

Zwar gibt es auch für Linux einen „X_fbdev-Treiber“, der das X-Window-System auf dem Linux-eigenen Grafikkartentreiber (siehe unten) aufsetzt, aber dieser bietet keine Hardwarebeschleunigung, und die meisten Fähigkeiten, die eine moderne Benutzeroberfläche ausmachen, wie z. B. Zeichensätze mit Kantenglättung, 3D-Spiele, Verschieben von Fenstern mit angezeigtem Inhalt usw. sind mit dieser Variante nicht sinnvoll möglich. In der Regel wird der X-fbdev-Server nur in Kombination mit dem generischen VESA-fbdev-Treiber (der auf fast jedem x86-basierten Rechner mit Grafikhardware funktioniert) und nur in den folgenden Situationen gebraucht:

• Als Behelf, wenn kein X-Treiber für eine bestimmte Grafikkarte existiert, wohl aber ein fbdev-Treiber.
• In der Installationsphase eines Linux-Betriebssystems, bevor die Grafikhardware erkannt wird und entsprechende X-Treiber installiert sind.

Framebuffer Device (fbdev)

Der „fbdev-Treiber“ von Linux ist ein betriebssystemabhängiger Kernel-Mode-Treiber für Grafikkarten, auf dem man beliebige Anwendungen aufsetzen kann. Die Grafikkartenhersteller unterstützen die Entwicklung von fbdev-Treibern bisher wenig, mit dem Argument, dass schon das XFree-Modell unterstützt werde und fbdev daher nicht benötigt wird. So führt fbdev in gewisser Weise ein Schattendasein, es fehlten lange Zeit und außer für die Grafikkarten eines einzigen Herstellers bis heute wichtige Funktionen wie Hardwarebeschleunigung und eine einheitliche Usermode-Grafikbibliothek (z. B. OpenGL), die diesen Treiber erst zu einer vollwertigen Grafikschnittstelle machen würden. Zudem ist fbdev als Kernel-Mode-Treiber nicht beliebig erweiterbar, da für Kernel-Mode-Treiber die Stabilität und Leistungsfähigkeit des Betriebssystems an sich absolute Priorität hat. Der zurzeit am häufigsten verwendete fbdev-Treiber ist der generische VESA-Treiber. Er unterstützt die VESA-Hardwarespezifikation, die von den meisten momentan am Markt befindlichen Grafikchips als „kleinster gemeinsamer Nenner“ angeboten wird. Es fehlen jedoch gerade hier Möglichkeiten zum Ändern der Bildschirmauflösung im laufenden Betrieb, zur Programmierung von Videofrequenzen und vieles mehr, sowie 2D- oder 3D-Beschleunigungsfunktionen.

DRI

Im Zuge der Entwicklung von 3D-Hardwaresupport unter X hat sich die Direct Rendering Infrastructure (DRI) entwickelt, die parallel zum Xfree-Treiber einen weiteren Zugang zur Hardware ermöglicht. Der Grafikkartenhersteller ATI, der eigene Treiber für seine Produkte unter Linux mitliefert, unterstützt in seinen proprietären Treibern ebendiese Schnittstelle. Nvidia, ein anderer wichtiger Grafikkartenhersteller, hat jedoch ein eigenes, proprietäres Kernel-Interface für 3D-Beschleunigung entwickelt.

Probleme der aktuellen XFree-Architektur

• Ein Grundprinzip von Betriebssystemarchitekturen besagt, dass immer nur ein einziger Treiber gleichzeitig auf die gleiche Hardware zugreifen kann. Unter Linux sind jedoch meist zwei Treiber, nämlich fbdev in der Boot-phase und für die Textkonsole, und X für die grafische Oberfläche geladen. Das führt dazu, dass bei der Treiberentwicklung ein Umschalten zwischen den beiden Treibern berücksichtigt werden muss, d. h. es müssen Routinen für das Speichern und Wiederherstellen des Hardwarezustands einprogrammiert werden, die die grafische Oberfläche nach einem Umschalten auf die Textkonsole wieder genauso herstellen, wie sie vor den Zugriffen des jeweils anderen Treibers auf die Hardware war. Gerade diese Routinen sind aber schwierig zu programmieren und zu warten und sind somit auch einer der häufigsten Gründe für Ärgernisse mit Grafiktreibern unter Linux.
• Von Hardwareherstellern werden wegen der Verbreitung des XFree-Standards eigene Treiber für deren Hardware nur für den Xfree-Standard angeboten. Andere Windowing-Systeme, die zum Teil modernere Konzepte verfolgen, haben aus diesem Grund unter Linux bisher keinen Erfolg – sie sind schwierig zu installieren und funktional sehr eingeschränkt.
• Für manche Anwendungen (z. B. Linux auf reinen Spielekonsolen) wird im Grunde kein Windowing-System benötigt, wohl aber beschleunigte Grafik. Solche Anwendungen müssen momentan in der Regel als Pseudo-X-Anwendungen entwickelt werden, d. h. es muss das gesamte X11-System installiert und konfiguriert werden, und danach wird nur ein einziges Fenster ohne Rahmen geöffnet (bzw. es wird über eine X-Server-Erweiterung in einen Vollbildmodus geschaltet) worin dann die eigentliche Anwendung abläuft. Die Verfügbarkeit von Hardwaretreibern, die unabhängig vom Windowing-System sind, würde diesen Aufwand sparen.
• Beschleunigte Grafik z. B. mit OpenGL war in der ursprünglichen X11-Spezifikation nicht vorgesehen. Daher hat sich mit der Zeit ein Wald von X-Erweiterungen entwickelt, die alle gesondert vom Treiber unterstützt und konfiguriert werden müssen. Die aktuelle GLX-Erweiterung, die OpenGL innerhalb von X ermöglicht, greift z. B. über DRI (oder entsprechenden proprietären Treiber) am X-Server vorbei auf die Hardware zu. Dadurch wird die Architektur komplexer als notwendig und viele Funktionalitäten sind redundant implementiert. Außerdem kann der X-Server selbst die Möglichkeiten, die sich durch die hardwarebeschleunigte Grafik und OpenGL ergaben, nicht in seiner eigenen Implementierung nutzen.

Der Lösungsansatz Xegl

Mit Xegl wird das X-Window-System auf einem davon völlig unabhängigen Hardwaretreiber aufgesetzt und dabei wird auch der X Server mit allen Möglichkeiten moderner Hardware ausgestattet. Unter Xegl können daher z. B. auch einfache Fensteroperationen direkt mit OpenGL-Unterstützung ausgeführt werden. Die Trennung zwischen Benutzeroberflächenfunktionen und hardwarebeschleunigter Grafik entfällt damit.

Die Implementierung von Xegl basiert auf dem framebuffer-Device fbdev in Zusammenarbeit mit DRI, OpenGL und einer weiteren 2D-Grafikbibliothek (Cairo). Als OpenGL-Implementierung kommt eine spezielle Version der Mesa-3D-Bibliothek zum Einsatz, die auch ohne X11 lauffähig ist aber dennoch Hardwarebeschleunigung über DRI unterstützt.

Die Basismodule, d. h. fbdev, DRI, OpenGL und Cairo können dabei auch ohne X11 benutzt werden. Würden für diese Architektur von Open-Source-Projekten oder von den Hardwareanbietern Treiber entwickelt (was diese auch angekündigt haben), so könnten diese also auch für andere Anwendungen außerhalb von X benutzt werden. Außerdem entfällt die Problematik des Umschaltens zwischen verschiedenen Treibern, denn der Zustand der Hardware (z. B. Bildschirmauflösung, Video-Frequenzen) wird einzig und alleine vom fbdev-Treiber verwaltet. Das vereinfacht einige Dinge erheblich, am auffälligsten dürfte sein, dass das Starten von X etwas schneller geht und keine sichtbaren Umschaltungsartefakte (Flackern, Dunkelphasen usw.) mehr auftreten. Ebenso ist die gesamte Konfiguration der Grafikhardware, die momentan in Xorg.conf stattfindet, obsolet. Bildschirmauflösungen u. Ä. werden dann über die Konfiguration des fbdev definiert.

Ein weiterer Vorteil ist die Entkopplung des Treibers von X11-Anforderungen auch bei der Weiterentwicklung, d. h. Treiberentwickler können sich zukünftig tatsächlich auf die eigentliche Hardwaretreiberentwicklung konzentrieren und X.org kann die Entwicklung visueller Effekte, Netzwerkprotokolle, Zeichensatzverwaltung usw. vorantreiben.

Weniger Wert wird nunmehr auf die Betriebssystemunabhängigkeit des eigentlichen Treibers gelegt, die ursprünglich von den XFree86-Entwicklern als wichtiges Ziel angesehen wurde. Dieses Ziel ist jedoch vor allem durch die gestiegene Bedeutung des Linux-Betriebssystems am Markt in den Hintergrund getreten. Zudem könnte man durch eine gezielte Lizenzierung (z. B. MIT) es auch nicht-GPL-basierten Open-Source-Projekten ermöglichen, diese komplette Treiberinfrastruktur auf ihr System zu portieren, bei proprietären Treibern sind diese allerdings in selber Weise wie Linux vom guten Willen der Grafikkartenhersteller abhängig.

Siehe auch

• Wayland, voraussichtlicher Nachfolger des X11-Protokolls
• Mesa 3D, Open-Source OpenGL-Implementierung
• X Window System
• XFree86, ursprüngliche Entwickler der bisherigen Linux X11-Architektur
• X.Org Foundation, Dachorganisation für Spezifikation des X-Protokolls, seit einiger Zeit auch Dachorganisation für die Weiterentwicklung einer Abspaltung des XFree86-Servers.
• Framebuffer, Erläuterungen zum Sinn und zur Funktionsweise eines Framebuffers.
• Direct Rendering Infrastructure
• Xgl: Mithilfe von OpenGL implementierter X-Server, der jedoch im Gegensatz zu Xegl noch auf einen anderen, herkömmlichen X-Server aufsetzt (Xgl-Server läuft als Anwendung auf einem anderen X-Server).

Weblinks

• Projektseite des Freedesktop-EGL (Memento vom 11. November 2012 im Internet Archive)
• Offizielle Projektseite des Xegl-Projekts
• Übersicht und Spezifikation der EGL-Schnittstelle