I dream a dream.

Archive for September, 2012

Notes about Framebuffer [DRAG]

1. What is FrameBuffer?

Source

1.1 Definition

  • A Framebuffer (or sometimes Framestore) is a video output device that drives a video display from a memory buffer containing a complete frame of data.
  • The information in the memory buffer typically consists of color values for every pixel (point that can be displayed) on the screen
  • Color values are commonly stored in 1-bit binary (monochrome), 4-bit palettized, 8-bit palettized, 16-bit highcolor and 24-bit truecolor formats. An additional alpha channel is sometimes used to retain information about pixel transparency.
  • With a framebuffer, the electron beam (if the display technology uses one) is commanded to trace a left-to-right, top-to-bottom path across the entire screen, the way a television renders a broadcast signal

1.2 Display mode

  • Framebuffers used in personal and home computing often had sets of defined "modes" under which the framebuffer could operate. These modes would automatically reconfigure the hardware to output different resolutions, color depths, memory layouts and refresh rate timings. In the world of Unix machines and operating systems, such conveniences were usually eschewed in favor of directly manipulating the hardware settings.
  • Modern CRT monitors introduces a "smart" protection circuitry. When the display mode is changed, the monitor attempts to obtain a signal lock on the new refresh frequency. If the monitor is unable to obtain a signal lock, or if the signal is outside the range of its design limitations, the monitor will ignore the framebuffer signal and possibly present the user with an error message.
  • LCD monitors tend to contain similar protection circuitry, but for different reasons. Since the LCD must digitally sample the display signal (thereby emulating an electron beam), any signal that is out of range cannot be physically displayed on the monitor.

1.3. Color Palette   

  • Framebuffers have traditionally supported a wide variety of color modes. Due to the expense of memory, most early framebuffers used 1-bit (2 color), 2-bit (4 color), 4-bit (16 color) or 8-bit (256 color) color depths. The problem with such small color depths is that a full range of colors cannot be produced. The solution to this problem was to add a lookup table to the framebuffers. Each "color" stored in framebuffer memory would act as a color index; this scheme was sometimes called "indexed color".
  • The lookup table served as a palette that contained data to define a limited number (such as 256) of different colors. However, each of those [256] colors, itself, was defined by more than 8 bits, such as 24 bits, eight of them for each of the three primary colors. With 24 bits available, colors can be defined far more subtly and exactly
  • The data from the framebuffer in this scheme determined which of the [256] colors in the palette was for the current pixel
  • The framebuffer’s output data, instead of providing relatively color data, served as an index – a number – to choose one entry in the lookup table.

1.4. Virtual Framebuffers.

  • Many systems attempt to emulate the function of a framebuffer device, often for reasons of compatibility. The two most common "virtual" framebuffers are the Linux framebuffer device (fbdev) and the X Virtual Framebuffer (Xvfb)
  • The Linux framebuffer device was developed to abstract the physical method for accessing the underlying framebuffer into a guaranteed memory map that is easy for programs to access. This increases portability, as programs are not required to deal with systems that have disjointed memory maps or require bank switching.

Advertisements