Framebuffer how to programming guide

Original article: http://www.ummon.eu/Linux/API/Devices/framebuffer.html

Note: This article is Wiebe zoon;
Part of the wiebe@linvision.com, the original English version, this article from highbar
Translation. If the record is reproduced, indicate the original author and the translator.

7. framebuffer

7.1 Introduction to framebuffer

This is a document on how to program. Therefore, configure yourFramebufferDevice.

UseFramebufferDevice. You can use your computer screen as a real graphical device. You can modify the resolution, update rate, and color depth. The best thing is that you can plot the pixels wherever you want.FramebufferA device is not a graphics library, but a low-level general-purpose device. This creates great flexibility, but it also has its shortcomings. Want to useFramebufferDevice, you should do the following:

• Determine that most of the devices you are using are/dev/fb0.
  
• Enable the device
• Get or change Screen Settings
• Map Screen memory

The device is usually/dev/fb0, but the device may be different if the user has multiple video cards and monitors. Most applications read environment variables
Framebuffer(Use getenv ();)
To determine which device to use. If the environment variable does not exist, use/dev/fb0.

Open the device by calling open (). Reading the device means reading the screen memory (which can be called a video memory ). Use
$ CAT/dev/fb0> screenshot
Import the screen memory into a file. You can use $ cat screenshot>/dev/fb0 to restore the screen.

7.2 basic device usage

Obviously, using the above method to use the screen memory is not economical and convenient. Continuous addressing before reading or writing (see man lseek) will cause a lot of overhead. That's why you need to map your screen memory. When you map the screen memory to your application, you will get a pointer pointing directly to the screen memory.

Before we can map the screen memory, we need to know how much we can map and how much we need to map. The first thing we need to do is get new information from us.FramebufferThe device retrieves information. There are two structures that contain the information we need. The first one contains fixed screen information, which is determined by the hardware and drive capabilities, and the second one contains variable screen information, this part is determined by the current hardware status and can be changed by the user space program calling IOCTL.

struct fb_fix_screeninfo {char id[16]; ??????????????????????? /*identification string eg "TT Builtin" */unsigned long smem_start; /*Start of frame buffer mem *//* (physical address) */__u32 smem_len; /* Length of frame buffer mem */__u32 type; /* see FB_TYPE_* */__u32 type_aux; /* Interleave for interleaved Planes*/__u32 visual; /* see FB_VISUAL_* */__u16 xpanstep; /* zero if no hardware panning?*/__u16 ypanstep; /* zero if no hardware panning?*/__u16 ywrapstep; /* zero if no hardware ywrap???*/__u32 line_length; /* length of a line in bytes???*/unsigned long mmio_start; /*Start of Memory Mapped I/O?? *//* (physical address) */__u32 mmio_len; /* Length of Memory Mapped I/O?*/__u32 accel; /* Type of acceleration available */__u16 reserved[3]; /* Reserved for future compatibility*/}; 

The most important domain here isSmem_lenAnd
Line-length. Smem-Len
Tell usFramebufferThe size of the device. The second field tells us how many bytes the pointer should forward to get the data in the next row.

The second structure is much more interesting. It gives us information that can be changed.

/* more kernel header files copied shamelessly */struct fb_bitfield {__u32 offset; /* beginning of bitfield */__u32 length; /* length of bitfield */__u32 msb_right; /* != 0 : Most significant bit is *//* right */};struct fb_var_screeninfo {__u32 xres; /* visible resolution */__u32 yres;__u32 xres_virtual; /* virtual resolution */__u32 yres_virtual;__u32 xoffset; /* offset from virtual to visible */__u32 yoffset; /* resolution */__u32 bits_per_pixel; /* guess what */__u32 grayscale; /* != 0 Graylevels instead of colors*/struct fb_bitfield red; /*bitfield in fb mem if true color, */struct fb_bitfield green; /*else only length is significant */struct fb_bitfield blue;struct fb_bitfield transp; /*transparency */__u32 nonstd; /* != 0 Non standard pixel format */__u32 activate; /* see FB_ACTIVATE_* */__u32 height; /* height of picture in mm???*/__u32 width; /* width of picture in mm????*/__u32 accel_flags; /* acceleration flags (hints) *//* Timing: All values in pixclocks, except pixclock (ofcourse) */__u32 pixclock; /* pixel clock in ps (pico seconds) */__u32 left_margin; /* time from sync to picture */__u32 right_margin; /* time from picture to sync */__u32 upper_margin; /* time from sync to picture */__u32 lower_margin;__u32 hsync_len; /* length of horizontal sync */__u32 vsync_len; /* length of vertical sync */__u32 sync; /* see FB_SYNC_* */__u32 vmode; /* see FB_VMODE_* */__u32 reserved[6]; /* Reserved for future compatibility*/}; 

The first few members determine the resolution.XresAnd yres are the actual resolutions visible on the screen, and the usual VGA mode will be 640 and 400 (maybe 480, byhighbar ). * Res-virtual determines how the video card reads the screen memory when building the screen. When the actual vertical resolution is 400, the virtual resolution can be 800. This means that 800 rows of data are stored in the screen memory area. Because only 400 rows can be displayed, it is up to you to decide from that row. This can be achieved by setting * offset. If 0 is assigned to yoffset, the first 400 rows are displayed. If 35 is assigned, the first 36th rows to 435th rows are displayed. This is repeated. This feature is very convenient and practical in many cases. It can be used for double buffering. Dual buffering is the memory allocated by your program to fill two screens. Setting the offset to 0 will display the first 400 rows (assuming the standard VGA), and you can secretly build another screen from lines 400 to lines 799. When the build ends, set yoffset to 400, and the new screen will be displayed immediately. Now we will start to build the data for the next screen in the first memory area. This is very useful in animation.

Another application is used to smoothly scroll the entire screen. Just as on the front screen, allocate 800 rows of space in the memory. Set a timer (timer, see man settimer and man signal/man sigaction) every 10 milliseconds to set the offset to 1 or more than the previous one, you see a smooth scrolling screen. Make sure that your signal (signal) is not blocked by the signal processing program due to the best output.

Set bits_per_pixel to 1, 2, 4, 8, 16, 24, or 32 to change the color depth (color depth ). Not all video cards and drivers support full color depth. When the color depth changes, the driver automatically changes FB-bitfields. These indicate how many bits and which bits are used in a specific color benchmark. If bits-per-pixel is less than 8, FB-bitfields is not defined and color ing is enabled.

The scheduled setting at the end of the FB-var-screeninfo structure is used to set the video timing when you choose a new resolution. (
Examine and explain timings! )

Now we know the structure details, but we still don't know how to get or set them. Here are some IOCTL commands for reference.

    #include    int main () {    int framebuffer_handler;    struct fb_fix_screeninfo fixed_info;    struct fb_var_screeninfo variable_info;    open ("/dev/fb0", O_RDWR); /*in real life, check every ioctl if it returns -1 */    ioctl (framebuffer_handler,FBIOGET_VSCREENINFO, &variable_info); variable_info.bits_per_pixel = 32;    ioctl(framebuffer_handler, FBIOPUT_VSCREENINFO, &variable_info);    ioctl (framebuffer_handler,FBIOGET_FSCREENINFO, &fixed_info);    variable_info.yoffset = 513;    ioctl (framebuffer_handler,FBIOPAN_DISPLAY, &variable_info);    } 

These fbioget _*? The IOCTL command writes the request information to the struct pointed to by the last variable. Fbioput_vscreeninfo copies all provided information back to the kernel. If the kernel cannot activate the new settings,-1 is returned. While

Fbiopan_display also copies information from the user, but does not reinitialize the video mode. It is best to use it when only xoffset or yoffset is changed.

7.3 video memory management

To access the memory itself, it can be mapped and then accessed directly. However, some steps are required:

• Calculate the number of mappings required
• Ing memory
• Determine how to build a screen
• Write Data to the screen

Here is an example:

#include#include#include#include#include#include#includeint main() {int framebuffer_device;int line_size,buffer_size, *i;int *screen_memory;struct fb_var_screeninfo var_info;framebuffer_device = open ( "/dev/fb0" , O_RDWR);ioctl (framebuffer_device, FBIOGET_VSCREENINFO, &var_info);line_size = var_info.xres * var_info.bits_per_pixel / 8;buffer_size = line_size * var_info.yres;var_info.xoffset = 0;var_info.yoffset = 0;ioctl (framebuffer_device, FBIOPAN_DISPLAY,&var_info) == -1);screen_memory = (char *) mmap (513, buffer_size, PROT_READ | PROT_WRITE, MAP_SHARED, framebuffer_device, 0);for (i=0;i < buffer_size ; i++ ){*(screen_memory+i) = i%236;}sleep(2);return 0;}

You can see that we have used the information retrieved from the previous section, and the MMAP function is used in this section. The first variable can be ignored in this case, the second is the memory size mapped, and the third variable declares that we will read and write the shared memory. The fourth variable indicates that the memory will be shared with other processes. InFramebufferIt is impossible to create a map_private. This usually means that you need to interrupt the console switch to back up and restore the screen content, and do not write to the screen memory when you have no right.