Taken from Geert Uytterhoeven's framebuffer.txt in the linux kernel sources:
A framebuffer device is an abstraction for the graphic hardware. It represents the frame buffer of some video hardware, and allows application software to access the graphic hardware through a well-defined interface, so that the software doesn't need to know anything about the low-level interface stuff.
The frame buffer device is a very low-level interface to display something on the screen. Speaking about an embedded GUI there are several reasons to use the frame buffer directly instead of a Window manager:
- simple: just write the pixels to a memory
- fast: no window manager which means fast boot and less overhead
- portable: independently from the distribution every Linux system has a frame buffer device so it's compatible with all of them
More detailed information can be found in the great manifest for Raspberry Pi Wiki about the framebuffer and the framebuffer console.
Single C source file should compile well on any Unix OS with make
command:
make [all|clean]
It leverages Make implicit rules.
For fbinfo
, see low level graphics on Raspberry Pi. For fbmmap
,
see enabling the linux framebuffer from Qt docs.
One may need sudo
depending on the file permissions to run dd.
Error like No space left on device
is expected.
# Output random pixel noise
dd if=/dev/urandom of=/dev/fb0
# Clear framebuffer
dd if=/dev/zero of=/dev/fb0
Print detailed information. Optional fb
parameter to fall back on default.
fbset -fb /dev/fb0 -i
Initialize the framebuffer if disabled by a remapping of the framebuffer
console via a kernel parameter. Soft reset when coupled with
clear framebuffer command. A call like con2fbmap 1 0
is needed to actually get
the framebuffer working with linuxfb
API.
fbset -fb /dev/fb0 "640x480-60"
See /etc/fb.modes
.
vt.global_cursor_default=0
Add this kernel parameter to disable console framebuffer fb0
:
fbcon=map:1
From The Framebuffer Console:
3 . fbcon=map:<0123>
This is an interesting option. It tells which driver gets mapped to which console. The value '0123' is a sequence that gets repeated until the total length is 64 which is the number of consoles available. In the above example, it is expanded to 012301230123... and the mapping will be:
tty | 1 2 3 4 5 6 7 8 9 ... fb | 0 1 2 3 0 1 2 3 0 ...
(
cat /proc/fb
should tell you what the fb numbers are)
One side effect that may be useful is using a map value that exceeds the number of loaded fb drivers. For example, if only one driver is available, >
fb0
, addingfbcon=map:1
tells fbcon not to take over the console.
Later on, when you want to map the console the to the framebuffer device, you can use the
con2fbmap
utility.
More details about the con2fbmap utility. With hints here on where to put such a piece of code.
As per Linux Framebuffer drivers for small TFT LCD display:
2015-01-19 The FBTFT drivers are now in the Linux kernel staging tree: https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/fbtft?h=staging-testing Development in this github repo has ceased.
If one wants to read someone struggling to setup its LCD driver at boot, as of Octobre 2015. Hence a little outdated.
Read the Framebuffer API official documentation:
This document describes the frame buffer API used by applications to interact with frame buffer devices. In-kernel APIs between device drivers and the frame buffer core are not described.
Due to a lack of documentation in the original frame buffer API, drivers behaviours differ in subtle (and not so subtle) ways. This document describes the recommended API implementation, but applications should be prepared to deal with different behaviours
Read the Framebuffer HOWTO by Alex Buell (2010):
This document describes how to use the framebuffer devices in Linux with a variety of platforms. This also includes how to set up multi-headed displays.
Some chapters that are interesting in our case:
Table of Contents
1. Contributors
2. What is a framebuffer device?
3. What advantages does framebuffer devices have?
4. Using framebuffer devices on x86 platforms
10. Using framebuffer devices on ARM platforms
13. Changing Console Modes
17. Looking for further information
Read the interesting documentation from Toradex.
The framebuffer (fbdev) is a character device providing access to graphics hardware. Beside the framebuffer, other interfaces exist to access graphics hardware such as the DRI (direct rendering interface) or proprietary interfaces (NVIDIA drivers).
Typically, the framebuffer doesn't support any 2D/3D hardware acceleration.
The i.MX 6 kernel comes with an open source fbdev driver called mxcfb. The X-Server driver is closed source and called vivante.
The i.MX 7 and i.MX 6ULL kernels come with an open source fbdev driver, mxsfb.