Das Framebuffer Device erlaubt es, Bilder und Videos auf der Konsole darzustellen. Wir zeigen, wie Sie den Framebuffer aktivieren und sinnvoll nutzen können.

Lange Zeit war das Anzeigen von Bildern oder Videofilmen der grafischen Oberfläche X11 vorbehalten – wer sich Bilder anschauen wollte, kam um die Installation und (oft aufwendige) Konfiguration von XFree86 nicht herum. Mit dem Linux Kernel 2.2 hielt dann das Framebuffer Device Einzug in die Linux-Welt, und es wurde möglich, Bilder und sogar Videofilme auf der Konsole ohne Qualitätsverlust anzuzeigen. Bevor wir uns mit dem eigentlichen Framebuffer Device genauer beschäftigen, möchte ich zum besseren Verständnis noch darauf hinweisen, dass die eigentliche Textkonsole, die in jedem Kernel standardmäßig aktiviert ist, und der Framebuffer im Kernel streng voneinander getrennt sind. Beide laufen unabhängig.

Die Technik

Das Framebuffer Device repräsentiert im System den Speicher der Grafikkarte und übernimmt die Koordination mit ihr. Es stellt gleichzeitig eine einheitliche Schnittstelle im /dev-Verzeichnis zur Verfügung, über die die verschiedenen Programme auf den Speicher der Grafikkarte indirekt zugreifen können. Die Programme, die auf der Konsole Bilder und Videofilme darstellen, kommunizieren also nicht direkt mit der Karte, sondern benutzen das Framebuffer Device als “Dolmetscher” zum System. Die dafür erforderlichen Schnittstellen werden über Gerätedateien in /dev angesprochen. Das erste Framebuffer Device im System verwendet /dev/fb0, das zweite /dev/fb1 usw.

Die Konfiguration

Viele große Distributoren wie SuSE, Red Hat oder Mandrake unterstützen die Verwendung des Framebuffers bereits in ihren Standard-Kernels. Hierbei handelt es sich jedoch meist nur um den generischen VesaFB. Dieser Framebuffer-Treiber soll theoretisch mit allen Grafikkarten funktionieren, die mit dem Vesa 2.0 Standard kompatibel sind – die Praxis sieht leider anders aus: Bei manchen exotischen Grafik-Chipsätzen streicht der VesaFB die Segel. Außerdem besitzt VesaFB keinerlei Optimierungen und kann höchstens mit 16 MB Videospeicher umgehen. Das heißt nicht, dass Grafikkarten mit größerem Videospeicher nicht funktionieren. Der VesaFB erzielt hier jedoch oft nur schlechte Resultate, die den eigentlichen Möglichkeiten des Framebuffer Devices nicht gerecht werden.

Um den Framebuffer nutzen zu können, muss er im Kernel aktivieren werden. Laden Sie sich dazu zuerst die Quellen des aktuellen Linux-Kernels 2.4.18 ([5]) herunter. Konfigurieren und kompilieren Sie den Kernel danach so, wie beispielsweise im LinuxUser 03/2001 auf Seite 86 beschrieben. Um den Framebuffer im Kernel zu aktivieren, müssen die folgenden Dinge, unabhängig von Ihrer Grafikkarte, fest in den Kernel (nicht etwa als Modul) einkompiliert werden:

• “Prompt for development and/or incomplete code/drivers” im Menüpunkt “Code maturity level options”
• “Video mode selection support” im Menüpunkt “Console drivers”
• “Support for frame buffer devices (EXPERIMENTAL)” im Menüpunkt “Console drivers/Frame-buffer support”

Aktivieren Sie danach im Menüpunkt “Console drivers/Frame-buffer support” den passenden Framebuffer-Treiber für Ihren Grafikkarten-Chipsatz. Die meisten Einträge erklären sich dabei von selbst, ansonsten kann bei Ratlosigkeit ein Klick auf die “Help” Buttons Klarheit schaffen. Wird Ihr Grafikkarten-Chipsatz nicht ausdrücklich in der Liste oder in den Hilfetexten zum Treiber erwähnt, ist davon auszugehen, dass es für diesen Chipsatz noch keinen speziellen FB-Treiber gibt. In dem Fall wählen Sie den Eintrag “VESA VGA graphics console” für den VesaFB aus. Nach dieser Konfiguration können Sie den Kernel kompilieren und installieren.

Boot Manager lilo

Wenn der Kernel fertig übersetzt ist, nehmen Sie in der Datei /etc/lilo.conf noch eine Änderung vor, um den Framebuffer zu aktivieren – sonst bleibt’s bei einer Konsole mit 80×25 Zeichen oder im schlimmsten Falle bei einem schwarzen Bildschirm. Um den Framebuffer zu konfigurieren, muss dem Kernel bereits beim Booten ein Argument mit dem richtigen Video Mode übergegeben werden. Bei diesen Argumenten gibt es jedoch große Unterschiede: Fast jeder Framebuffer-Treiber benötigt andere Argumente, und nicht bei jedem lassen sich alle Eigenschaften bestimmen. So lassen sich beispielsweise beim generischen VesaFB momentan nur der Videomodus selbst und die Größe des Grafikspeichers auf der Karte bestimmen, beim MatroxFB kann man zusätzlich die gewünschte Farbtiefe angeben. Zwar gibt es bereits die sogenannte ModeDB, die die verschiedenen Video Modes der einzelnen Framebuffer-Treiber vereinheitlichen soll – diese ModeDB konnte sich bis jetzt jedoch nicht durchsetzen und wird zur Zeit nur von vier Framebuffer-Treibern benutzt.

Beim VesaFB reicht es, dem Kernel vga=0x318 mit auf den Weg zu geben, um eine Framebuffer-Auflösung von 1024×768 Pixeln bei 16 MB Grafikkartenspeicher zu erreichen. Beim Framebuffer für Matrox-Karten (matroxfb) wird selbiges durch den Eintrag video=matrox:vesa:0x192 bewirkt – der Videospeicher wird in der Regel automatisch erkannt. Beim aty128-Framebuffer, einem der vier Framebuffer-Treiber, die die ModeDB bereits benutzen, heißt der Eintrag video=aty128fb:1024x768. Der VesaFB stellt bei der Angabe der Argumente eine Ausnahme dar; er benötigt als einziger Treiber ein Argument in der Form vga=xxx, alle anderenFB-Treiber verwenden die Syntax video=xxx:yyy. Das Argument für einen VesaFB wird in der Datei lilo.conf direkt über dem Schlüsselwort “vga” eingetragen, für Argumente in der Form video=xxx:yyy benötigen Sie eine append-Zeile.

Ein Eintrag in der Datei lilo.conf bei Verwendung des VesaFBs und einer gewünschten Auflösung von 1024×768 Pixeln bei 16 MB Videospeicher könnte so aussehen:

lba32
boot=/dev/hda
delay=20
promptvga=0x318
[…]

Für eine Grafikkarte mit ATI-Rage128-Chipsatz, in der der “aty128”-Framebuffer zum Einsatz kommt, sieht der Eintrag in lilo.conf wie folgt aus (die gewünschte Bildwiederholungs-Frequenz beträgt hier 60 Hz, die Farbtiefe 16 bpp):

lba32
boot=/dev/hda
delay=20
promptappend="video=aty128fb:1024x768-16@60"
[…]

Tabelle 1 listet einige typische Konfigurationen auf; wir gehen jeweils von einer Farbtiefe von 16 bpp und einer Bildwiederholungrate von 60 Hz aus.

Ist der richtige Framebuffer-Modus in der Datei lilo.conf eingetragen, muss vom Benutzer root noch das Kommando lilo auf der Kommandozeile ausgeführt werden. Ob alles geklappt hat, lässt sich nach einem Reboot mit dem Kommando dmesg feststellen. Bei einer Matrox G450 liefert der Aufruf dmesg | grep fb0 beispielsweise fb0: MATROX VGA frame buffer device.

Sonderfall Matrox

Besitzer einer Matrox-Grafikkarte haben Glück: Der Framebuffer-Treiber für Matrox-Grafikkarten (MatroxFB) funktioniert nicht nur ausgezeichnet und wird deswegen momentan als bester Framebuffer-Treiber betrachtet, er bietet bei Matrox-Karten mit einem zweitem VGA-Ausgang sogar Dual-Head-Unterstützung. Ist der MatroxFB richtig konfiguriert, verfügt jeder der beiden VGA-Ausgänge der Karte über einen eigenen – vom anderen unabhängigen – Framebuffer. Damit ist es möglich, auf dem zweiten Monitor zu arbeiten, während auf dem ersten Monitor eine TV-Anwendung läuft – und das alles ohne XFree86.

Wir beschreiben nun die Konfiguration des MatroxFBs anhand einer Matrox G450DH mit zwei VGA-Ausgängen. Bei der Kernel-Konfiguration müssen im Untermenü “Console drivers/Frame-buffer support” die folgenden Optionen aktiviert werden: “Matrox acceleration (EXPERIMENTAL)”, “G100/G200/G400/G450/G550 support” und “G450/G550 second head support (mandatory for G550)”.

Die Aktivierung von “Multihead support” ist nicht nötig. Nach Übersetzen und Installieren des neuen Kernels muss in der Datei lilo.conf die richtige append-Zeile für den ersten Monitor eingetragen werden. Die Konfiguration des zweiten Monitors wird weiter unten besprochen. Die passenden Video Modes entnehmen Sie bitte der Tabelle “Kernel-Argumente für Framebuffer und Video Modes”.

Ist der neue Kernel installiert, der richtige Video Mode in der Datei lilo.conf eingetragen und der Bootsektor der Festplatte mittels lilo aktualisiert, kann der Rechner neu gestartet werden. Nach dem Reboot verfügt dann jeder der beiden VGA-Ausgänge über einen eigenen Framebuffer, der über die jeweilige Benutzerschnittstelle im /dev-Verzeichnis angesprochen werden kann. Der erste VGA-Ausgang benutzt dabei /dev/fb0, der zweite /dev/fb1.

Man sollte nicht in Panik geraten, wenn der Monitor am zweiten VGA-Anschluss beim Booten schwarz bleibt: Standardmäßig wird der zweite Framebuffer nicht benötigt und infolgedessen auch nicht geladen. Um den zweiten Monitor nutzen zu können, müssen Sie auch hier zuerst die erforderlichen Daten wie Auflösung, Farbtiefe und Bildwiederholrate einstellen. Dies geht mit dem fbset-Programm, welches jeder aktuellen Distribution entweder als RPM- oder Debian-Paket beiliegt.

fbset liest die Video Modes aus der Datei /etc/fb.modes, die im gleichen Paket wie fbset liegt. In ihr sind die wichtigsten Auflösungen bereits eingetragen, so dass es möglich ist, die Video Modes bei fbset ähnlich anzugeben wie die Kernel-Argumente bei Framebuffer-Treibern, die die ModeDB benutzen. Als Beispiel für den zweiten Monitor nehmen wir hier einen Modus, der sich besonders zum Fernsehen und zum Anzeigen von Bildern mit dem Framebuffer eignet: 768×576 Bildpunkte bei 75 Hz. Das Kommando, um den zweiten Monitor in diesen Modus zu versetzen, lautet:

fbset -fb /dev/fb1 768x576-75

DirectFB

Der schönste Framebuffer nützt wenig, wenn man keine Anwendungen hat, um ihn zu verwenden. Normale Anwendungen wie Mozilla, GIMP oder Xmms sind fest mit der X11-Oberfläche verwoben und funktionieren deswegen nicht mit dem Framebuffer Device. Auch wollen einige Bibliotheken mit dem Framebuffer nicht so recht zusammen arbeiten – beispielsweise die GTK+-Bibliothek. Um auf der Konsole Bilder anzuschauen oder fernzusehen, benötigt es also einige Extra-Programme. Primär genügen dafür die Tools fbi und fbtv, die aktuellen Distributionen beiliegen.

Wenn die Möglichkeiten des Framebuffers vollständig ausgeschöpft werden sollen, kommt man um den Einsatz der DirectFB Library ([1]) kaum herum. Bei DirectFB handelt es sich um eine Bibliothek, die Hardware-Beschleunigung auf Basis des Framebuffer Devices erlaubt. Der Geschwindigkeitsgewinn, der durch die Benutzung von DirectFB entsteht, ist so groß, dass es mit dem Programm mplayer ([2]) sogar möglich ist, Videofilme auf der Konsole zu schauen. Ein weiterer großer Vorteil von DirectFB ist die ausgesprochen schnelle 2D-Beschleunigung.

Futurama

Momentan tut sich viel bei der Framebuffer-Entwicklung: So soll in Kürze eine komplett überarbeitete Version des XDirectFB ([3]) veröffentlicht werden. Hierbei handelt es sich um eine Art “XFree86 ohne XFree86”. Mit dem XDirectFB sowie der speziell für den DirectFB angepassten Version von GTK+ ([4]) wird es bald sogar möglich sein, komplette Window Manager und Programme wie GIMP ohne X11 zu betreiben.