{"id":117,"date":"2009-03-30T23:12:14","date_gmt":"2009-03-30T22:12:14","guid":{"rendered":"http:\/\/www.instruyete.org\/?p=117"},"modified":"2009-03-30T23:12:14","modified_gmt":"2009-03-30T22:12:14","slug":"das-x-windows-universum-auf-linux","status":"publish","type":"post","link":"https:\/\/www.instruyete.org\/?p=117","title":{"rendered":"Das X-Windows Universum auf Linux"},"content":{"rendered":"

Wenn alle Tage neue Features eingef\u00fchrt werden, Buzzwords inflation\u00e4r auftauchen, alte Gewohnheiten nicht mehr gelten\u00a0 und dadurch Probleme bei der t\u00e4glichen Arbeit entstehen wird es mal wieder Zeit sich einen \u00dcberblick \u00fcber den Stand der Technik zu verschaffen.<\/p>\n

Wie jeder weiss ist Linux nur der Betriebssystemkern. Alle graphischen Anwendungen, sei es das komplette Desktopsytem wie KDE oder Gnome, als auch einzelne Anwendungen, wie Grafikprogramme oder Spiele ben\u00f6tigen ein X-Window System.<\/p>\n

X.Org<\/strong> ist unter Linux die Referenzimplementierung<\/em> dieses Systems und liegt derzeit in der Version 7.4<\/strong> vor. Die X.Org Foundation<\/em> sah sich urspr\u00fcnglich nur f\u00fcr X-Standards verantwortlich, w\u00e4hrend XFree86<\/strong> das Projekt war, dass die eigentliche Implementierung mit dem xserver<\/strong> als Kernbestandteil, zur Verf\u00fcgung stellte.
\nDie Entwicklung im XFree86 Projekt war allerdings recht tr\u00e4ge und f\u00fchrte dazu, dass der Innovationsabstand zwischen X-Windows auf UNIX Systemen gegen\u00fcber MS Windows und Mac OS X immer gr\u00f6sser wurde. Als im Jahr 2003 dann Streitigkeiten \u00fcber eine neue Lizenz aufkeimten, zogen viele Entwickler die Notbremse und gr\u00fcndeten die neue X.Org-Stiftung die nun ebenfalls eine X-Window Implementation herausbrachte.
\nInnerhalb k\u00fcrzester Zeit erschien X.Org 6.8<\/strong> auf Basis von XFree86 4.4, welches dann nacheinander von allen Distributionen als Standard X-Windows System installiert wurde.<\/p>\n

Erstes Ziel war die Modularisierung<\/em> um die Grafiktreiberprogrammierung zu erleichtern und eine ausbauf\u00e4hige Grundlage f\u00fcr zuk\u00fcnftige Modernisierungen zu schaffen. Dieses Ziel wurde mit X.Org 7.0<\/strong> erreicht.<\/p>\n

Mit dem Aufkommen der Composite Window Manager<\/em> einerseits und dem Eintreten von Intel<\/strong> als GPU Hersteller andererseits kam eine f\u00fcr dieses Projekt ungekannte Dynamik ins Spiel. Daf\u00fcr sind jetzt eine Reihe von Begriffskl\u00e4rungen notwendig:<\/p>\n

xserver<\/h4>\n

W\u00e4hrend X.Org die Agglomeration aller am X-Windows System beteiligten Komponenten ist, also inkludierte Grafiktreiber, Keyboard Treiber, X-Video Erweiterung, stellt der xserver die zentrale Komponente des Systems dar.
\nMit erscheinen von X.Org 7.4 wurde xserver in Version 1.5.2 mitgeliefert. Im Februar 2009 erschien dann aber xserver 1.6.0 ohne ein gleichzeitiges Minor Update von X.Org. Der neue xserver integriert sich stattdessen in X.Org 7.4 und stellt neue Features, allen voran DRI2<\/strong> bereit.<\/p>\n

Direct Rendering Interface (DRI)<\/h4>\n

Komponenten, die es Applikationen erlauben, innerhalb des X-Window Systems, die Video Hardware direkt<\/em>, unter Umgehung des xservers, anzusprechen.<\/p>\n

Die Beteiligten Komponenten sind:
\n– Kerneltreiber<\/em> (Direct Rendering Manager<\/strong>, DRM) <\/strong>der eine Schnittstelle zur Grafikkarte bereitstellt
\n– Userland Treiber<\/em> innerhalb des MESA<\/strong> Projektes.<\/p>\n

Seit 2000 (XFree86 4.0) war DRI1<\/strong> die Major Revision, welches OpenGL Applikationen veranlasst direkt auf den Framebuffer zu zeichnen. Mit Erscheinen des xservers 1.6 wurde DRI2<\/strong> released. Dies erlaubt jetzt die Umleitung auf ein Offscreen Memory<\/em>, so dass der Compositing Manager verschiedene Str\u00f6me zusammen verarbeiten kann. DRI2 erfordert aber ein neues Grafik-Speichermanagement, names GEM.<\/strong><\/p>\n

Derzeit unterst\u00fctzen alle Open-Source Treiber sowie der propriet\u00e4re AMD\/ATI Grafiktreiber DRI1. Intel unterst\u00fctzt seit der Intel Grafiktreiberversion 2.6 auch DRI2, ben\u00f6tigt aber damit GEM und implizit damit mindestens Kernel 2.6.28.<\/p>\n

Der propriet\u00e4re nVIDIA<\/strong> Grafiktreiber hat ein v\u00f6llig eigenst\u00e4ndiges Direct Rendering Konzept welches im Kerneltreibermodule realisiert wird.<\/p>\n

MESA<\/h4>\n

Mesa ist eine Open Source 3D Grafikbibliothek welche eine generische OpenGL Implementation zur Verf\u00fcgung stellt.<\/p>\n

Eine OpenGL Anwendung linkt dabei gegen \/usr\/lib\/libGL.so.X<\/strong><\/p>\n

Mesa sorgt daf\u00fcr, dass diese Datei ein softlink zur MESA (OpenGL) Bibliothek darstellt. Weiterhin st\u00fctzt sich diese Bibliothek entweder auf eine passende DRI Bibliothek der Grafikkarte – und damit direktes (hardwareunterst\u00fctztes) Rendering<\/em> oder er f\u00e4llt auf indirektes (softwaregest\u00fctztes) Rendering<\/em> zur\u00fcck.<\/p>\n

Da der propriet\u00e4re nVIDIA Treiber die DRI Architektur nicht unterst\u00fctzt, muss allein schon deshalb der softlink von \/usr\/lib\/libGL.so.X auf die eigene OpenGL Biblitohek zeigen, welche die OpenGL Kommandos dann in Hardwarebefehle umsetzen kann.<\/p>\n

Memory Management \/ GEM<\/h4>\n

Bis xserver 1.6 haben ausnahmslos alle Grafiktreiber die Verwaltung des Grafikspeichers selbst implementiert.
\nMit DRI2 wird jetzt erstmals – mit dem Graphics Execution Manager<\/strong> (GEM<\/strong>) <\/strong>– ein generischer Memory Manager f\u00fcr GPU’s vom Kernel (ab 2.6.28) bereitgestellt. Er kontrolliert den Ausf\u00fchrungskontext und managt NUMA<\/strong> auf modernen Grafikkarten. Verschiedene Applikationen k\u00f6nnen nun GPU Ressourcen teilen ohne GPU state changes<\/em> selber verwalten zu m\u00fcssen.
\nGEM wird derzeit nur vom Intel Treiber 2.6.0<\/strong> verwendet.<\/p>\n

X Rendering Extension (XRender)<\/h4>\n

Stellt eine Komponente f\u00fcr Porter-Duff Image Compositing<\/em> und Alpha-Blending<\/em> bereit. Gedacht war diese Erweiterung v.a. f\u00fcr Antialiased Schriften, wird aber auch f\u00fcr alle m\u00f6glichen Desktop Effekte genutzt. XRender st\u00fctzt sich massgeblich auf die 2D Beschleunigungsarchitektur von X.Org ab.<\/p>\n

Unter den KDE4 Systemeinstellungen<\/em> kann man w\u00e4hlen, ob die Desktop Effekte via OpenGL<\/strong> (also DRI, oder nVIDIA Direct Rendering) oder XRender<\/strong> ausgef\u00fchrt wird.<\/p>\n

2D Beschleunigung<\/h4>\n

W\u00e4hrend mit DRI+MESA bzw. nVIDIA’s eigener Architektur, die 3D Funktionalit\u00e4t bereitgestellt wird, gibt es im 2D Bereich eine eigene Subkomponente.
\nSeit 1996 exisitert mit dem Modul XAA<\/strong> (XFree86 Acceleration Architecture<\/strong>) eine Treiberarchitektur die es erm\u00f6glicht auf die 2D Hardwarebeschleunigung von GPU’s zuzugreifen.
\nDa XAA viele 2D Operationen sowie XRender nicht mehr gen\u00fcgend beschleunigte und zus\u00e4tzlich erhebliche Probleme mit Compositing Window Manager hat (siehe xVideo<\/strong>) wurde mit X.Org 7.0 EXA<\/strong> als \u00dcbergangsl\u00f6sung bis zum vollst\u00e4ndigen 3D Desktop vorgestellt. EXA sollte schlank sein und XRender so gut wie m\u00f6glich unterst\u00fctzen. Mittlerweile unterst\u00fctzen viele Grafiktreiber dieses Modul.
\nGanz neu ist UXA<\/strong>, eine EXA Reimplementation , entwickelt von Intel<\/strong> & Tungsten Graphics<\/strong>, unter Zuhilfenahme von GEM<\/strong>.<\/p>\n

nVIDIA unterst\u00fctzt defaultm\u00e4ssig direkt die hardwarebeschleunigung der XRender Extension und damit die 2D Befehle.<\/p>\n

X Video extension (Xv\/XVideo)<\/h4>\n

Video Ausgabe Mechanismus des X-Window Sytems. Haupt Usecase ist die Skalierung von Videowiedergabe in der Video Controller Hardware, bspw. f\u00fcr Vollbilddarstellung<\/em>.
\nWenn allerdings die Compositing Erweiterung des Window Managers eingestellt ist, werden Programme die Xv in Kombination mit XAA<\/strong> benutzen –\u00a0 wie VLC – sofort mit folgender Meldung terminieren<\/strong>:<\/p>\n

X11 error: BadAlloc (insufficient resources for operation)<\/pre>\n
Grund daf\u00fcr ist, dass der XAA Beschleuniger kein Mechanismus beherscht um Pixmaps vom Systemspeicher<\/strong> in das Video RAM<\/strong> zu laden.<\/p>\n
X Resize and Rotate Extension (XRandR)<\/h4>\n
Erlaubt es X clients<\/strong> dynamisch X Screens<\/strong> zu vergr\u00f6\u00dfern\/verkleinern und zu rotieren. Generell geht es darum die Display Charakteristik zu ver\u00e4ndern, ohne den xserver neu starten zu m\u00fcssen.
\nXRandR unterst\u00fctzt (derzeit) nicht<\/em> Multi-Screens, bei denen ein WindowManager mehrere Screens verwaltet, die allerdings nicht durchg\u00e4ngig sind. Xinerama<\/strong> Mode wird dagegen unterst\u00fctzt. Bei diesem Mode spannen mehrere Monitore einen grossen virtuellen Screen<\/strong> auf. Dieser Mode heisst bei nVIDIA TwinView<\/strong> und kann \u00fcber das nVIDIA eigene Setting Tool angew\u00e4hlt werden.
\nDa Xinerama\/TwinView einen grossen virtuellen Screen aufspannt, ben\u00f6tigt man dadurch wesentlich mehr VRAM. Auch wenn die Menge an verf\u00fcgbarem VRAM stark gestiegen ist, muss man sich im klaren sein, dass bei eingeschaltetem Antialiasing der Memory sehr schnell ausgesch\u00f6pft sein wird (siehe Full Screen Antialiasing<\/a>)<\/p>\n
XRandR<\/strong> lag lange Zeit in Version 1.2<\/strong> vor und wurde mit xserver 1.6 auf Version 1.3<\/strong> upgedatet. Neu ist u.a. das Panning Feature<\/em>.
\nXRandr l\u00e4sst sich mit dem gleichnamigen (kleinschreibung beachten) Kommandotool bedienen. Ein Generisches GUI oder die Integration in die bekannten Desktop Systeme – Gnome<\/strong> und KDE<\/strong> – l\u00e4sst auf sich warten. Einzelne Features lassen sich aus GPU Settings Applikationen der Hersteller bedienen, so bspw. TwinView mittels nvidia-settings<\/strong>.<\/p>\n
X Input Extension<\/h4>\n
Zust\u00e4ndig f\u00fcr Einrichtung und Abfrage von Eingabeger\u00e4ten. Mit xserver 1.6 wurde X Input 1.5<\/strong> vorgestellt, welches neben Vereinfachungen auch Predictable Pointer Acceleration<\/em> einf\u00fchrt, welches verbesserte und beschleunigte Darstellung des Mauszeigers bietet.<\/p>\n
Gallium 3D<\/h4>\n
Eines der vielversprechendsten Projekte innerhalb des X-Window System seit langen. Unter der Federf\u00fchrung von Tungsten Graphics<\/strong>, welche im Auftrag von Intel deren Grafiktreiber erstellt, entsteht langfristig ein neuer Layer anstatt der MESA<->DRI<\/strong> Kombination.<\/p>\n
Das Gallium API kann als Input unterschiedliche<\/em> Grafikbibliotheken – OpenGL, Direct3D.. – verarbeiten und hat nur noch ein backend, den sog. State Tracker<\/em>.
\nGrafikkartentreiber m\u00fcssen nur noch diesen State-Tracker verarbeiten – bisher muss f\u00fcr jeden Grafikkartentreiber ein angepasstes mesa-DRI Modul<\/strong> geschrieben werden. Zudem benutzt Gallium3D unter Linux auch das Kernel Memory Management – GEM – wobei Gallium selber plattformneutral ist.
\nMit einem dummy-Treiber lassen sich sogar Ergebnisse von nicht vorhandener GPU-Hardware simulieren.
\nOb dieses Modul tats\u00e4chlich in den Produktiveinsatz kommt und ev. sogar \u00fcber die Grenzen von X.Org\/Linux sich durchsetzt kann derzeit noch nicht abgesch\u00e4tzt werden.<\/p>\n
Kernel Mode Settings<\/h4>\n
Dies ist die Bestrebung die bisher im Userland des xservers angesiedelten Modecodes in den Linux Kernel zu transferieren.
\nNeben der wiederholten Redundanzvermeidung wird es substantielle Verbesserungen geben:<\/p>\n