Framebuffer programming 2 (Simple Program)

1. Introduction to framebuffer Devices

With framebuffer, You can regard 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. The framebuffer device is not a graphics library, but more specifically a low-level general-purpose device. This creates great flexibility, but it also has its shortcomings. To use the framebuffer device, you should do the following:
1. Identify the device you are using
2. Open the device
3. Retrieve or change Screen Settings
4. 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 determine the device to use by reading the environment variable framebuffer (getenv. 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 to import the screen memory to a file. You can use $ cat screenshot>/dev/fb0 to restore the screen.

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 retrieve information from our new framebuffer device. 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 _**/
_ 2010xpanstep;/* zero if no hardware panning */
_ 2010ypanstep;/* zero if no hardware panning */
_ 2010ywrapstep;/* 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 */
_ 2010reserved [3];/* reserved for future compatibility */
};
The most important fields here are smem_len and line-length. Smem-len tells us the size of the framebuffer device, and the second field tells us how many bytes the pointer should forward to get the data of 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, blocks t pixclock (of course )*/
_ 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. Xres and yres are the actual resolutions visible on the screen. In common VGA mode, they will be 640 and 400 (maybe 480, by highbar ). * 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 every 10 milliseconds. For more information, see man settimer and man.
Signal/man sigaction), set the offset to 1 or more than last time. You can 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.