Der Framebuffer oder Bildspeicher (englisch frame – Einzelbild, buffer – Zwischenspeicher) ist Teil des Grafikspeichers von Computern und entspricht einer digitalen Kopie des Monitorbildes. Das heißt, jedem Bildschirmpixel kann genau ein bestimmter Bereich des Framebuffers zugewiesen werden, der dessen digital übersetzten Farbwert enthält. Seit den 1990er-Jahren befindet sich der Framebuffer vorwiegend auf der Grafikkarte.

Speicherbedarf

Die minimal benötigte Größe des Framebuffers ist abhängig von zwei Faktoren: der verwendeten Farbtiefe (genauer: Pixelformat) und der verwendeten Bildauflösung.

Beispiele

• Textmodus (z. B. beim Hochfahren eines IBM-kompatiblen PCs mit BIOS)
  Bei einer 80 × 25 Zeichen großen Konsole, wobei jedes Zeichen und seine Farbe mit jeweils 8 Bit (also zusammen 16 Bit) gespeichert wird, belegt der Framebuffer 80 × 25 × 16 = 32000 Bit = 4 KB.
• EFI-Framebuffer bei modernen PCs mit Unified Extensible Firmware Interface (UEFI)
  Bei EFI 1.x war mit Universal Graphics Adapter (UGA) ein von der Hardware unabhängiger EFI-Treiber verfügbar, um einen einfachen Video-Framebuffer zu nutzen. Dieser wurde mit UEFI 2.x durch das Graphics Output Protocol (GOP) ersetzt, das nun auch den Textmodus unabhängig von der Grafikkarte nutzen kann. Sowohl UGA als auch GOP ersetzt das Video-BIOS (kurz VBIOS, nur auf PCs mit BIOS) vollständig – VBIOS-Funktionen sind somit auch vom Grafiktreiber nicht mehr nutzbar, sodass einige ältere PC-Grafiktreiber unter (U)EFI bei identischer Hardware nicht funktionieren, bei aktiviertem CSM (der BIOS-Emulation von EFI bzw. UEFI) jedoch schon. Betriebssysteme und Gerätetreiber müssen daher EFI-UGA oder -GOP nutzen, um den Text- (bei GOP) oder Videomodus und weitere Firmware-Framebuffer-Funktionen nutzen zu können. Unter Linux existiert mit efifb ein generischer Framebuffer-Grafiktreiber, der auf allen EFI-PCs, und daher auch unabhängig von der spezifischen Grafikkarte, funktioniert. Auch Windows und macOS nutzen den EFI-Framebuffer, da er jedoch nur ohne Grafikbeschleunigung zur Verfügung steht, nur in einem eingeschränkten Modus.
• Grafikmodus (z. B. unter Windows oder beim X Window System unter Unix)
  Bei einer Bildschirmauflösung von 1024 × 768 Pixel und einer Farbtiefe von 24 Bit belegt der Framebuffer 1024 × 768 × 24 = 18874368 Bit = 2,25 MiB.

In der Übersicht wurde im Fall von TrueColor berücksichtigt, dass Daten intern mit 24 Bit gespeichert werden.

Verbesserungen

Durch Unzulänglichkeiten in der Kontinuität der Bildfolge, und um die allgemeine Darstellungsqualität weiter zu erhöhen, wurde das Konzept des Framebuffers im Laufe der Zeit überarbeitet. So entspricht ein Framebuffer auf aktuellen Systemen mehreren Pufferspeichern.

• Bei der Doppelpufferung (double buffering) wird der Framebuffer in zwei Bereiche (Frontbuffer und Backbuffer) unterteilt.
• Bei der Dreifachpufferung (triple buffering) wird der Framebuffer in drei Bereiche (1 Frontbuffer und 2 Backbuffer) unterteilt.

Linux-Framebuffer

Das Linux Framebuffer Device (kurz fbdev) ist eine hardwareunabhängige Abstraktionsschicht unter Linux, um Grafiken auf der Konsole bzw. mit X-Window (xf86_fbdev) anzuzeigen. Dabei setzt das Framebuffer-Device nicht auf systemspezifischen Bibliotheken wie der SVGALib oder dem X Window System auf und ist somit eine ressourcensparende Alternative zum weiterverbreiteten X-Server, auf dem heute die meisten grafischen Oberflächen für Linux aufbauen. Es ist seit der Linux-Kernelversion 2.1.107 für alle Plattformen im Standardkernel enthalten.

Ursprünglich wurde es für Linux68k implementiert, um auf entsprechenden Systemen (Amiga, Atari, Macintosh) mit einer geringen Hardwarebeschleunigung einen Textmodus zu emulieren und wurde erst später auf die IBM-PC-kompatible Plattform erweitert.

Heutzutage kann der Framebuffer direkt von verschiedenen Programmen wie MPlayer und Bibliotheken wie GGI, SDL, GTK und Qt Extended benutzt werden. Das ressourcensparende Konzept macht den Einsatz besonders für eingebettete Systeme interessant.

Insbesondere wird es von verschiedenen Distributionen (Ubuntu, openSUSE) verwendet, um schon während des Bootstrappings in Form eines Splash Screens eine grafische Ausgabe zu ermöglichen.

Der am häufigsten verwendete VESA-Framebuffer-Treiber (vesafb) baut auf einheitlichen Spezifikationen von Videostandards auf und erlaubt so einen Zugriff auf Grafikkarten größtenteils unabhängig vom Hersteller. Dadurch ist dann auch eine quelloffene Implementation möglich. Außerdem wurden von diversen Grafikchipherstellern (Nvidia: rivafb, nvidiafb; AMD: radeonfb) proprietäre Treiber auf den Markt gebracht.

Bekannt wurde das Framebuffer-Device durch die Möglichkeit, während des Linux-Kernel-Ladevorgangs dem Benutzer ein Tux-Logo anzuzeigen. Dazu muss es aber zunächst im Kernel enthalten sein und beim nächsten Reboot durch den Bootloader, der auch das Betriebssystem in den Arbeitsspeicher lädt, durch die Angabe des Parameters video aktiviert werden.

Im Folgenden werden zwei Beispiele gezeigt, in denen ein AMD-Treiber mit einer Bildauflösung von 1024×768 Bildpunkten bei einer Farbtiefe von 8 Bit pro Pixel und einer Bildwiederholungsfrequenz von 76 Hz geladen wird:

Beispiel für eine LILO Konfigurationsdatei

# LILO configuration file
boot = /dev/sda1
# Linux bootable partition config begins
image = /vmlinuz
append = "video=atyfb:1024x768-8@76,font:SUN8x16"

Beispiel für eine GRUB Konfigurationsdatei

# GRUB configuration file
# For booting LINUX
title Linux
kernel (hd0, 0) /vmlinuz video=atyfb:1024x768-8@76,font:SUN8x16 root=/dev/hda1

Für einen Hardwarezugriff auf das Framebuffer-Device muss nicht unbedingt ein Kernelmodul geschrieben werden. Ferner hat die Anwendung die Möglichkeit, im User-Mode über die Gerätedatei /dev/fb* auf das Device zuzugreifen und in den Grafikspeicher zu schreiben. In folgendem Beispiel wird demonstriert, wie mit der Programmiersprache C linear in den Framebuffer geschrieben werden kann. Hier wird der hexadezimale Wert 0x000000FF (Binär: 0b00000000000000000000000011111111) für jedes Pixel gesetzt:

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <linux/fb.h>
#include <unistd.h>
#include <stdio.h>

int main(int argc, char **argv) {
   int row, col, width, height, bitspp, bytespp;
   unsigned int *data;

   // Öffnen des Gerätes
   int fd = open("/dev/fb0", O_RDWR);

   // Informationen über den Framebuffer einholen
   struct fb_var_screeninfo screeninfo;
   ioctl(fd, FBIOGET_VSCREENINFO, &screeninfo);

   // Beende, wenn die Farbauflösung nicht 32 Bit pro Pixel entspricht
   bitspp = screeninfo.bits_per_pixel;
   if(bitspp != 32) {
     // Ausgabe der Fehlermeldung
     printf("Farbaufloesung = %i Bits pro Pixel\n", bitspp);
     printf("Bitte aendern Sie die Farbtiefe auf 32 Bits pro Pixel\n");
     close(fd);
     return 1; // Für den Programmabbruch geben wir einen Rückgabetyp != 0 aus.
   }

   width  = screeninfo.xres;
   height = screeninfo.yres;
   bytespp = bitspp/8; //Bytes pro Pixel berechnen

   // Überprüfen ob der Typ unsigned int die gleiche Byte-Grösse wie ein Pixel besitzt.
   // In unserem Fall 4 Byte (32 Bit), falls nicht wird das Programm beendet
   if(sizeof(unsigned int) != bytespp) {
      close(fd);
      return 1;
   }

   // Zeiger auf den Framebufferspeicher anfordern
   data = (unsigned int*) mmap(0, width * height * bytespp, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

   // In den Framebuffer-Speicher schreiben. Hier wird Pixel für Pixel auf
   // die Farbe 0x000000FF (Blau) gesetzt, da ein Pixel das AARRGGBB Format hat
   for(row = 0; row < height; row++)
     for(col = 0; col < width; col++)
        data[row * width + col] = 0xFF;

   // Zeiger wieder freigeben
   munmap(data, width * height * bytespp);

   // Gerät schließen
   close(fd);
   // Rückgabewert
   return 0;
}

Siehe auch

• DirectFB, Direct frame buffer, eine auf dem Linux frame buffer aufsetzende Programmbibliothek

Einzelnachweise

1. ↑ Edgar Hucek: What is efifb? In: The Linux Kernel Archives. Abgerufen am 25. August 2020 (englisch).