Framebuffer

The frame buffer or image memory (English frame - single image, buffer - intermediate storage) is part of the graphics memory of computers and corresponds to a digital copy of the monitor image . This means that each screen pixel can be assigned a specific area of ​​the frame buffer that contains its digitally translated color value. Since the 1990s, the framebuffer has mainly been located on the graphics card .

Memory requirements

The minimum required size of the frame buffer depends on two factors: the color depth used (more precisely: pixel format) and the image resolution used .

Color depth

The color depth of the frame buffer defines the maximum number of colors or shades of color displayed on the screen at the same time. In the area of IBM PC-compatible computers , the sizes given in the following list were and are common. The specified pixel formats indicate how many bits per pixel are allocated to the individual color channels (red, green, blue, alpha channel ) - this information is missing for color modes that use indexed colors (palettes) because it does not make any sense.

• 1 bit per pixel, two colors (usually light and dark on a monochrome monitor )
  • MDA
• 2 bits per pixel, four colors
  • CGA : Palette with 4 colors out of 16 possible
• 4 bits per pixel, 16 colors
  • EGA : Palette with 16 colors out of 64 possible
• 8 bits per pixel, 256 colors
  • VGA : Palette with 256 colors out of 262144 possible
• 15 bits per pixel, 32768 colors
  • Real Color : pixel format 5-5-5, i.e. H. 5 bits per color channel (i.e. 32 intensity levels per channel)
• 16 bits per pixel, 65536 colors
  • High Color : pixel format 5-6-5, i.e. H. 5 bit for red and blue (32 intensity levels) and 6 bit for green (64 intensity levels)
  • alternatively also 4-4-4-4, i.e. H. 4 bits per color channel (16 intensity levels), whereby the last four bits are either unused or used as an alpha channel (see 32-bit true color)
• 24 bits per pixel: 16777216 colors
  • True Color : pixel format 8-8-8, i.e. H. 8 bits per color channel (256 intensity levels)
• 32 bits per pixel
  • True Color: pixel format 8-8-8-8, i.e. H. 8 bits per color channel (256 intensity levels)
  • The 8 bits that have been added to 24-bit True Color are normally not used; On computers with a 32-bit architecture, however, the processing of 32-bit values ​​is more efficient than that of 24-bit values, because this corresponds exactly to the word length of the processor, which is why true-color frame buffers mostly, despite the 33% higher memory requirement Use 32 bit color depth.

With graphics hardware that works with bitplanes (e.g. Amiga ), 3, 5, 6 and 7 bits per pixel with correspondingly 8, 32, 64 or 128 colors are also common for indexed colors.

In 3D computer graphics, frame buffers with higher accuracy are also used. There, the determination of the color of a pixel often requires several calculation steps, whereby rounding errors can occur with every intermediate result, which are quickly visible with conventional frame buffer formats and have a disruptive effect.

With these more precise formats, the color channel values ​​are interpreted as comma values ​​on a scale from 0.0 to 1.0, so that handling is simplified when using several pixel formats.

• FX8
  • 8 bit fixed point per color channel, thus 256 color gradations scaled linearly
  • identical to the above 32 bits per pixel. Whether you take the 256 different values ​​per color channel as a whole number between 0 and 255 or as a fixed point value between 0.0 and 1.0 is only a matter of interpretation. ${\displaystyle \left({\frac {\text{Wert}}{255}}\right)}$
  • maximum contrast 255: 1, therefore suitable for low dynamic range (LDR) rendering, as can be displayed by normal screens of all kinds
• FX12
  • 12 bit fixed point per color channel, thus 4096 color gradations scaled linearly
  • higher accuracy than FX8
  • maximum contrast 4095: 1, suitable for Low Dynamic Range (LDR) rendering
• FX16
  • 16 bit fixed point per color channel, thus 65536 color gradations scaled linearly
  • higher accuracy than FX12
  • maximum contrast 65535: 1, suitable for Medium Dynamic Range (MDR) rendering
• FP16
  • 16 bit floating point per color channel (of which 5 bit exponent and 10 bit mantissa ), thus 32768 color gradations scaled exponentially
  • Compared to the FX16, the exponential scale allows a much finer resolution for small values, but it is less precise for larger values.
  • maximum contrast approx. , suitable for high dynamic range (HDR) rendering . ${\displaystyle 10^{12}:1}$
• FP24
  • 24-bit floating point per color channel (of which 7-bit exponent and 16-bit mantissa), thus more than 8 million color gradations scaled exponentially
  • higher accuracy than FP16, therefore very suitable for HDR rendering
• FP32
  • 32-bit floating point per color channel (thereof 8-bit exponent and 23-bit mantissa), thus more than 2 billion color gradations scaled exponentially
  • even higher accuracy than FP24

Image resolution

The image resolution indicates how many pixels the frame buffer consists of. Usually you specify the horizontal and vertical number of pixels, which means that the aspect ratio can also be calculated directly; 4: 3, 5: 4 and 16:10 are common here.

Typical framebuffer resolution:

• 320 × 200: 64,000 pixels, aspect ratio 16:10
• 640 × 200: 128,000 pixels, aspect ratio 32:10 (usually shown anamorphically as 16:10 on standard 4: 3 screens )
• 640 × 480: 307,200 pixels, aspect ratio 4: 3
• 800 × 600: 480,000 pixels, aspect ratio 4: 3
• 1024 × 768: 786,432 pixels, aspect ratio 4: 3
• 1280 × 1024: 1.31 million pixels, aspect ratio 5: 4
• 1440 × 900: 1.3 million pixels, aspect ratio 16:10
• 1680 × 1050: 1.76 million pixels, aspect ratio 16:10
• 1600 × 1200: 1.92 million pixels, aspect ratio 4: 3
• 1920 × 1200: 2.3 million pixels, aspect ratio 16:10
• 2048 × 1536: 3.15 million pixels, aspect ratio 4: 3
• 2560 × 1600: 4.10 million pixels, aspect ratio 16:10

Examples

• Text mode (e.g. when booting an IBM-compatible PC with BIOS )
  In the case of an 80 × 25 character console, where each character and its color is saved with 8 bits each (i.e. a total of 16 bits), the frame buffer occupies 80 × 25 × 16 = 32000 bits = 4 KB.
• EFI frame buffer in modern PCs with Unified Extensible Firmware Interface (UEFI)
  With EFI 1.x, the Universal Graphics Adapter (UGA) was a hardware-independent EFI driver available to use a simple video frame buffer. This was replaced with UEFI 2.x by the Graphics Output Protocol (GOP), which can now also use the text mode independently of the graphics card. Both UGA and GOP completely replace the video BIOS (VBIOS for short, only on PCs with BIOS) - VBIOS functions can therefore no longer be used by the graphics driver, so that some older PC graphics drivers under (U) EFI do not work with identical hardware , but with activated CSM (the BIOS emulation of EFI or UEFI). Operating systems and device drivers must therefore use EFI-UGA or -GOP in order to be able to use the text (with GOP) or video mode and other firmware frame buffer functions. Linux exists withefifba generic framebuffer graphics driver that works on all EFI PCs and therefore also independent of the specific graphics card. Windows and macOS also use the EFI frame buffer, but since it is only available without graphics acceleration, only in a restricted mode.
• Graphics mode (e.g. under Windows or with the X Window System under Linux)
  With a screen resolution of 1024 × 768 pixels and a color depth of 24 bits, the frame buffer occupies 1024 × 768 × 24 = 18874368 bits = 2.25 MiB .

Width × height × colors	Memory requirement *	default
320 × 200 × 2	≈ 8 KB (8 kB)	C64
640 × 200 × 2	≈ 16 KB (16 kB)	CGA
750 × 350 × 2	≈ 32 KB	Hercules
640 × 350 × 16	≈ 109 KB (112 kB)	EGA
640 × 480 × 16	150 KB	VGA
320 × 200 × 256	62.5 KB (64 kB)	VGA
640 × 480 × 256	300 KB	VGA extended
800 × 600 × 256	468.75 KB (480 kB)	SVGA
1024 × 768 × 256	768 KB	XGA
1024 × 768 × 64k	1.5 MB	XGA
1024 × 768 × TrueColor	2.25 MB	XGA
1280 × 960 × TrueColor	≈ 3.5 MB	SXGA
1400 × 1050 × TrueColor	≈ 4.2 MB	SXGA +
1600 × 1200 × TrueColor	≈ 5.5 MB	UXGA
1920 × 1200 × TrueColor	≈ 6.6 MB	WUXGA
2048 × 1536 × TrueColor	9 MB	SUXGA
2560 × 960 × TrueColor	≈ 7 MB	Dual SXGA
2560 × 1600 × TrueColor	≈ 12 MB	WQXGA

^* here: 1 KB = 1024 bytes and 1 KB = 1000 bytes

In the case of TrueColor, the overview takes into account that data is stored internally with 24 bits.

Improvements

Due to inadequacies in the continuity of the image sequence and in order to further increase the general display quality, the concept of the frame buffer was revised over time. One frame buffer corresponds to several buffer memories on current systems.

• In the double buffering ( double buffering ) of the frame buffer into two regions (will front buffer and the back buffer ) divided.
• In the triple buffering ( triple buffering ) of the frame buffer is (1 in three areas front buffer and 2 BackBuffer divided).

Linux framebuffer

Knoppix booting screenshot

The Linux Framebuffer Device ( fbdev for short ) is a hardware-independent abstraction layer under Linux to display graphics on the console or with an X-Window (xf86_fbdev). The framebuffer device does not rely on system-specific libraries such as SVGALib or the X Window System and is therefore a resource-saving alternative to the widespread X server on which most graphical interfaces for Linux are based today. It has been included in the standard kernel for all platforms since Linux kernel version 2.1.107.

Originally it was implemented for Linux68k in order to emulate a text mode on corresponding systems (Amiga, Atari, Macintosh) with a low hardware acceleration and was only later extended to the IBM-PC-compatible platform.

Nowadays the framebuffer can be used directly by different programs like MPlayer and libraries like GGI, SDL , GTK + and Qt Extended . The resource-saving concept makes the use particularly interesting for embedded systems.

In particular, it is used by various distributions ( Ubuntu , openSUSE ) to enable graphical output in the form of a splash screen during bootstrapping .

The most frequently used VESA framebuffer driver (vesafb) is based on uniform specifications of video standards and thus allows access to graphics cards largely independent of the manufacturer. An open-source implementation is then also possible. In addition, various graphics chip manufacturers ( Nvidia : rivafb, nvidiafb; AMD : radeonfb) brought proprietary drivers onto the market.

The framebuffer device became known for its ability to display a Tux logo to the user while the Linux kernel is being loaded. To do this, it must first be contained in the kernel and activated by specifying the parameter during the next reboot by the boot loader , which also loads the operating system into the main memory video.

The following shows two examples in which an AMD driver is loaded with an image resolution of 1024 × 768 pixels, a color depth of 8 bits per pixel and a refresh rate of 76 Hz:

Example of a LILO configuration file

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

Example of a GRUB configuration file

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

A kernel module does not necessarily have to be written for hardware access to the frame buffer device. The application also has the option of /dev/fb*accessing the device in user mode via the device file and writing it to the graphics memory. The following example demonstrates how the programming language C can be used to write linearly into the frame buffer. Here the hexadecimal value 0x000000FF (binary: 0b00000000000000000000000011111111) is set for each pixel:

#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;
}

See also

• DirectFB , Direct frame buffer, a program library based on the Linux frame buffer

Individual evidence

1. ↑ Edgar Hucek: What is efifb? In: The Linux Kernel Archives. Retrieved on August 25, 2020 .