DAY47 FrameBuffer

FrameBuffer

1. Core Concepts of FrameBuffer

FrameBuffer is a character device abstraction layer provided by the Linux kernel for display devices (typically corresponding to the /dev/fb0 device file). Its core function is to map physical video memory to user space, allowing applications to directly control screen display by reading and writing memory without dealing with the underlying driver logic of LCD/displays.

1. Key Core Elements

• Video Memory Mapping (mmap) : This is the core feature of FrameBuffer. Using the mmap system call, the video memory address in kernel space is mapped to the address space of the user process. Reading and writing this memory region directly modifies the screen content, avoiding the performance overhead of frequent system calls.
• Screen Parameter Structure (fb_var_screeninfo) : This structure stores critical parameters of the display device, including:
  • Physical resolution (xres/yres): The actual pixel width and height of the screen.
  • Virtual resolution (xres_virtual/yres_virtual): The virtual width and height corresponding to the video memory (can be larger than the physical resolution for scrolling displays).
  • Bit depth (bits_per_pixel): The number of bits per pixel, commonly RGB565 (16-bit) or RGB888 (32-bit), which determines color representation.
• Color Formats: Different bit depths correspond to different color encoding methods. For example, RGB888 allocates 8 bits each to the red, green, and blue components, concatenated into a 32-bit integer, while RGB565 compresses them into 16 bits (5 bits for red, 6 bits for green, and 5 bits for blue), requiring format conversion for correct display.

2. Analysis of FrameBuffer Program Architecture

The practical code is divided into three modules, each with clear responsibilities and low coupling, representing a typical architecture for embedded graphics development:

• FrameBuffer Core Module (framebuffer.c/h): Handles device initialization, video memory mapping, and basic drawing APIs (points, lines, rectangles, circles, BMP rendering).
• UTF8 Font Processing Module (utf.c/h): Resolves the rendering of fixed-width characters like Chinese, including UTF8-to-Unicode conversion, font library loading, and bitmap rendering.
• Main Program (main.c): Integrates all modules to demonstrate actual graphics/text rendering.

3. Core Function Implementation Principles

1. FrameBuffer Initialization: Establishing Video Memory Access

Initialization is the first step in operating FrameBuffer, summarized as "open device → get parameters → map video memory":

1. Open Device File : Use open("/dev/fb0", O_RDWR) to open the framebuffer device and obtain a file descriptor.
2. Get Screen Parameters : Use ioctl(fd, FBIOGET_VSCREENINFO, &vinf) to read key parameters like resolution and bit depth, which are the basis for calculating video memory size and drawing graphics.
3. Map Video Memory to User Space : Calculate the total video memory size based on screen parameters (xres_virtual * yres_virtual * bits_per_pixel / 8), then call mmap to map the video memory to user space. The returned pointer directly points to the start of the video memory.

The key here is video memory size calculation : It must be based on virtual resolution, not physical resolution, to avoid out-of-bounds access. Additionally, mmap permissions should be set to PROT_READ | PROT_WRITE (readable and writable) and MAP_SHARED (shared mapping, ensuring modifications sync with kernel video memory).

2. Basic Graphics Drawing: "Point" as the Core Logic

All complex graphics are combinations of "points," making draw_point the core of the drawing system:

• Point Drawing Logic : Based on bit depth (RGB888/RGB565), select the appropriate pointer type (32-bit/16-bit unsigned integer). Calculate the target pixel's offset in video memory using y * xres_virtual + x, then assign the color value directly to draw the point.
• Derivation of Complex Graphics :
  • Lines (horizontal/vertical/diagonal): Horizontal lines are continuous points in the same row, vertical lines are continuous points in the same column, and diagonal lines are drawn by iterating over x-coordinates and calculating corresponding y-coordinates using the slope formula y = kx + b.
  • Rectangles: Composed of four lines (top, bottom, left, right).
  • Circles: Iterate over angles from 0 to 360 degrees, calculate the corresponding (x, y) coordinates using trigonometric functions, and draw points one by one (additional surrounding pixels are drawn for clarity).

3. BMP Image Rendering: Parsing Format and Adapting to Video Memory

BMP is a common image format in embedded systems. The core of rendering lies in parsing the BMP format + color format conversion:

1. Skip BMP File Header : The first 54 bytes of a BMP file are the file header/info header, skipped using lseek to directly read pixel data.
2. Handle BMP Pixel Storage: BMP pixel data is stored "bottom-to-top, left-to-right," so rendering must start from the last row.
3. Color Format Conversion : BMP pixel data is in RGB888 format (stored as blue, green, red). Convert it to RGB888 (direct concatenation) or RGB565 (compressed components) based on screen bit depth, then call draw_point for rendering.

4. Text Rendering: From ASCII to UTF8 Chinese

The core of text rendering is bitmap fonts---storing each character's shape as a binary bitmap and determining whether to draw pixels bit by bit during rendering:

• ASCII Character Rendering: Use predefined bitmap arrays (e.g., the 24x24 bitmap for the Chinese character "普" in the code), iterate row by row and bit by bit, and draw pixels where bits are 1.
• UTF8 Chinese Rendering : Fixed-width characters like Chinese require solving two problems: "encoding conversion + font library loading":
  1. UTF8 to Unicode : UTF8 is variable-length encoded. First, convert UTF8 strings to Unicode (via enc_utf8_to_unicode_one), using Unicode as the font library index.
  2. Font Library Loading : Load the pre-generated font file (containing bitmap data for all characters) into memory via mmap, then locate the font's starting address based on Unicode.
  3. Bitmap Rendering: Same logic as ASCII---parse font data bit by bit and draw character pixels.

4. Resource Release: Avoiding Memory Leaks

After using FrameBuffer, resources must be released:

1. Call munmap to unmap video memory from user space to prevent memory leaks.
2. Close the device file descriptor (close(fd)).
3. Free the font library memory (free).

5. Application Scenarios and Extensions of FrameBuffer

1. Typical Application Scenarios

• Embedded industrial control screens: For example, the "Remote Monitoring System for Aquaculture" in the code can implement simple monitoring interfaces using FrameBuffer.
• Smart home panels: Local displays for smart speakers, thermostats, etc.
• Embedded debugging tools: Quickly draw graphics and print debug information without relying on complex GUI libraries like Qt.

2. Extensible Directions

• Double Buffering: Create two video memory regions---one for drawing and one for display---to avoid screen flickering during rendering.
• Anti-Aliasing Optimization: Apply gradient processing to edges of lines and circles for better display quality.
• Graphics Layering: Render backgrounds, controls, and text in separate layers to simplify complex interface management.
• Touch Interaction: Integrate with the input subsystem to implement click, swipe, and other interactive logic.

6. Conclusion

FrameBuffer is a lightweight yet powerful tool for embedded Linux graphics development. Its core advantages are no dependencies, high performance, and low-level control---complex GUI libraries are unnecessary, as graphics rendering is achieved purely through memory operations. This article dissects the core logic, from video memory mapping and basic drawing to text rendering, using practical code. The essence is "using points as the core, combining them into complex graphics via mathematical logic, and achieving text rendering through encoding conversion + font libraries."