Page History

Framebuffer Character Driver

NX Graphics

NuttX has supported higher level graphics for some time with the OS's NX graphics subsystem and application oriented NxWidgets and the tiny window manager NxWM. These are higher level in the sensethat the primary graphical function is to support windowing and control of tools and toolbars within windows. These graphics tools often do not meet the needs of developers with very low end graphics and miminal display requirements.

Figure 1

The framebuffer character driver, along with the option LCD framebuffer interface, is an optional lighter-weight graphics interface.

http://nuttx.org/Images/GraphicsInterfaces.pngImage RemovedImage Added

Framebuffer Character Driver

A framebuffer character driver has been recently been added to bypass the complexity of NX and to provide a direct application interface to the framebuffer graphic device. The framebuffer buffer character devices, as with all character devices, provides the interface to the graphics device via stand POSIX VFS commands (open(), close(), read(), write(), seek(), ...), through IOCTL commands, and for this driver via the mmap() function. These interfaces are described below,

...

There is a simple example at apps/examples/fb that provides an illustration of most of the following interfacing methods.

POSIX Interfaces

The interaction with the framebuffer character driver via POSIX VFS interface calls is the same as for other character drivers. The only aspect that might require some additional discussion is the use of read(), write(), and seek().

...

While the framebuffer may be accessed with these POSIX interfaces, a more typical way of interacting with the framebuffer from an application would involve use of mmap() as described below.

IOCTL Commands

• FBIOGET_VIDEOINFO. Get color plane info. Its argument is pointer a writable instance of struct fb_videoinfo_s:

...

    struct nxgl_rect_s
    {
      struct nxgl_point_s pt1; /* Upper, left-hand corner */
      struct nxgl_point_s pt2; /* Lower, right-hand corner */
    };

mmap()

Above we talked about using read(), write(), and seek() to access the framebuffer. The simplest way to access the framebuffer, however, is by using the mmap() to map the framebuffer memory into the application memory space. The following mmap() command, for example, can be used to obtain a pointer to a read-able, write-able copy of the framebuffer:

...

Where fd is the file descriptor of the opened framebuffer character driver and fblen was obtained via an IOCTL command as described above. NOTE that the framebuffer buffer pointer is also available within the values returned by the IOCTL commands. The address is a kernel memory address and may not be valid in all build configurations. Hence, mmap() is the preferred, portable way to get the framebuffer address.

Framebuffer vs. LCD Graphics Drivers

Framebuffer graphics drivers are very common in high-end CPUs but most low-end, embedded hardware will not support a framebuffer.

...

Most low-end embedded MCUs have a much simpler hardware interface: The interface to the LCD may be through a simple parallel interface or, more commonly, through a slower serial interface such as SPI. In order to support such low-end hardware with the framebuffer character driver, a special software layer called the Framebuffer LCD Front End has been developed. This is the topic of the next paragraph.

LCD Framebuffer Front-End

The LCD Framebuffer Front-End provides a standard NuttX framebuffer interface, but works on top of a standard parallel or serial LCD driver. It provides the framebuffer, the framebuffer interface, and the hooks to adapt the LCD driver. The LCD framebuffer front-end can be found in the NuttX source tree at drivers/lcd/lcd_framebuffer.c.

...

As a caution, it is important to remember that a framebuffer can be quite large. For example, a 480x320 display with 16-bit RGB pixels would require an allocated framebuffer of size 300 KiB. This is inappropriate with most small MCUs (unless they support external memory). For tiny displays, such as 128x64 1-bit monochromatic displays, the framebuffer memory usage is not bad: 1 KiB in that example.

Framebuffer Graphics Library

Now the missing part is some kind of application-space framebuffer graphics library. The NuttX framebuffer driver is superficially similar to the Linux framebuffer driver so there is a lot of support for Linux framebuffer graphics support that should be easily ported to NuttX – Perhaps DirectFB would be an GPL option? SDL with its MIT license might be a more compatible source for such a port.