10

I have little background on how these hardware actually works, but now I'm required to learn how to write a Linux frame buffer driver for Android devices.

I'm confused by Linux graphics stack. From what I understand, on a desktop computer the compositing window manager interacts with DRM, which then sends data to specific video card driver. On the other hand there are some kind of controllers retrieving data from GPU's memory through DMA and send it to the monitor, as suggested by the answer here . Also by diagram at page 29 of this book, I figured that a frame buffer driver is on top of actual graphic devices, so it must need to interact with specific video card driver, for example, an nVidia driver.

But when I google writing a frame buffer driver for an embedded device, the results show that as if the driver is directly responsible for contacting with the LCD, so it looks like it's even below a video card driver.

So is a frame buffer driver actually a video card driver?

Community
  • 1
  • 1
Mingheng Wang
  • 125
  • 2
  • 9

1 Answers1

9

A framebuffer driver provides an interface for

  1. Modesetting
  2. Memory access to the video buffer
  3. Basic 2D acceleration operations (e.g. for scrolling)

To provide this interface, the framebuffer driver generally talks to the hardware directly.

For example, the vesafb framebuffer driver will use the VESA standard interface to talk to the video hardware. However, this standard is limited, so there isn't really much hardware acceleration going on and drawing is slow. Another example is the intelfb framebuffer driver. It talks to some intel hardware using a proprietary interface, that exposes more acceleration facilities, so it is faster.

Nowadays, KMS drivers are used instead for most hardware. They do both expose a framebuffer and also access to other GPU functionality, e.g. OpenGL, through DRM.

Your confusion seems to arise from the fact, that the framebuffer driver and the X11 GPU driver are in fact competing! This is why, if you have a KMS system, the switch between graphical and text consoles is instant, however, with a non-KMS system, it is slow, as both the fb driver and the X11 driver need to re-initialize the video hardware on console switch.

Find more information in the comprehensive talk Linux Graphics Demystified by Martin Fiedler: http://keyj.emphy.de/files/linuxgraphics_en.pdf

ypnos
  • 50,202
  • 14
  • 95
  • 141
  • 3
    Great, thanks for the response. So a framebuffer driver is a lesser GPU driver and even nVidia card must have some common interfaces for this kind of driver to use, though 3d acceleration stuff on such cards is dark secret. And does this also apply to an embedded device with a LCD, i.e. the frame buffer driver is not controlling the IC on a LCD but a GPU in SoC? – Mingheng Wang Aug 11 '16 at 11:03
  • 2
    There is the reverse-engineered `nouveau` driver for nvidia cards which provides KMS+fb, but also 3d acceleration in a limited and often unstable way. There is only few common interfaces, as mentioned, VESA being the most prominent one. On an embedded device it is possible to not have a dedicated GPU, see https://github.com/notro/fbtft/wiki for an example of a driver that talks to the LCD controller directly. – ypnos Aug 11 '16 at 12:28