Comprehensive framebuffer explanation

I. Principles of framebuffer
Framebuffer is a driver interface that appears in the 2.2.xx kernel.
Linux is working in the protection mode, so user-State processes cannot use the interrupt call provided in the graphics card BIOS as DOS to directly write the screen. Linux abstracts
The framebuffer device is used for user-State processes to write screens directly. The framebuffer mechanism imitates the function of the video card, abstracts the hardware structure of the video card, and can
The read and write operations of framebuffer are directly performed on the video memory. Users can regard framebuffer as an image showing the memory. After ing it to the process address space, they can directly perform read/write operations, and write operations can immediately respond to the screen. Such operations are abstract and unified. Users do not have to worry about the location of Physical video memory, page feed mechanism, and other details. These are
Framebuffer device driver.
But framebuffer itself does not have any ability to operate data, so it is better than a pool that temporarily stores water. The CPU puts the result after the operation into this pool, and the pool then streams the result to the monitor.
Data is not processed in the middle.
Applications can also directly read and write the contents of this pool. In this mechanism, although framebuffer requires the support of a real video card driver, all the display tasks are completed by the CPU, so the CPU
Heavy Load
The device files of framebuffer are usually/dev/fb0,/dev/Fb1, and so on.
Run the following command: # dd If =/dev/Zero of =/dev/FB to clear the screen.
If the display mode is 1024x7688-bit, run the command $ dd If =/dev/Zero of =/dev/fb0.
BS = 1024 COUNT = 768 clear the screen;
Run the command: # dd If =/dev/FB of = fbfile to save the content in FB;
You can write back the screen: # dd If = fbfile of =/dev/FB;
When framebuffer is used, Linux places the video card in graphic mode.

In applications
The device maps to the process address space. For example, the following program opens/dev/fb0.
Device, and perform address ing through MMAP system calls, and then use memset
Clear the screen (Here we assume the display mode is 1024x7688-bit color mode, linear memory mode ):

Int FB;
Unsigned char * fb_mem;
Fb = open ("/dev/fb0", o_rdwr );
Fb_mem = MMAP (null, 1024*768, prot_read | prot_write, map_shared, FB, 0 );
Memset (fb_mem, 0, 1024*768); // This command should only be executed by the root user

The framebuffer device also provides several IOCTL
Command to obtain some fixed information about the display device (such as the Display memory size) variable information related to the display mode (such as resolution, pixel structure, byte width of each scanned line), and color palette information in pseudo-color mode.
Through framebuffer
Device, you can also obtain the type of the accelerated display card supported by the current kernel (obtained through fixed information), which is usually related to a specific display chip. For example, the latest kernel (2.4.9) contains
S3, matrox, NVIDIA, and 3dfx
And so on. After obtaining the acceleration chip type, the application can
The memory I/O (memio) of the device is mapped to the address space of the process. These memio
It is generally used to control the registers of the display card. By operating these registers, the application can control the acceleration function of a specific video card.
PCI
The device can map its own control registers to the physical memory space. Then, access to these control registers becomes access to the physical memory. Therefore, these registers are also called "memio ". Once mapped to the physical memory
You can use MMAP
Map to the process address space so that you can directly access these registers.
Of course, because different display chips have different acceleration capabilities
The usage and definition are also different. In this case, you need to write different types of acceleration chips to implement different acceleration functions. For example, most chips provide hardware acceleration for Rectangle filling, but different chip implementation methods are different, you need to write different functions for filling the rectangle for different chip types.
Framebuffer
It is only a device that provides Display memory and display chip registers mapped from physical memory to process address space. Therefore, for applications, if you want
To program graphics on framebuffer, you also need to do a lot of other work by yourself.

II. Implementation and Mechanism of framebuffer in Linux
The source file of framebuffer is in the Linux/Drivers/Video/directory. The total abstract device file is fbcon. C, which contains the source files related to various graphics/card drivers.
// Take a good look at this file

(1) Analysis of framebuffer Device Drivers
The old VESA 1.2
Cards, such as CGA/HBA cards, do not support framebuffer, because framebuffer requires the video card to support linear frame buffering, that is, the CPU can access each bit in the explicit buffer, but VESA
The 1.2 card can only allow the CPU to access 64 KB of address space at a time.
The framebuffer device driver is based on the following two files:
1) Linux/include/Linux/FB. h
2) Linux/Drivers/Video/fbmem. c

The two files are analyzed below.
1. FB. h
Almost all the major structures are defined in this file. These structures include:
1) fb_var_screeninfo
This structure describes the features of the display card:
Note: _ u32 indicates unsigned 32 bits.
And the rest. This is Linux
The data type used in the kernel. If it is a user-space program, you can use
Unsigned long and so on.
Struct fb_var_screeninfo
{
_ U32 xres;/* visible resolution * // visible area
_ U32 yres;
_ U32 xres_virtual;/* virtual resolution * // visible area
_ U32 yres_virtual;
_ U32 xoffset;/* offset from virtual to visible resolution */
// Offset of the visible area
_ U32 yoffset;

_ U32 bits_per_pixel;/* Guess what * // number of bits per pixel
_ U32 grayscale ;/*! = 0 gray levels instead of colors * // if it is equal to zero, it becomes black and white.

Struct fb_bitfield red;/* bitfield in FB MEm if true color,
*/Haicai bit Mechanism
Struct fb_bitfield green;/* else only length is significant */
Struct fb_bitfield blue;
Struct fb_bitfield Transp;/* Transparency */transparent

_ U32 nonstd ;/*! = 0 non standard pixel format */not standard format

_ U32 activate;/* See fb_activate _**/

_ U32 height;/* Height of picture in mm */Image Height in memory
_ U32 width;/* width of picture in mm */Image Width in memory

_ U32 accel_flags;/* acceleration flags (hints) */acceleration flag

/* Timing: All values in pixclocks, blocks t pixclock (of course )*/

Time Series-_-these parts are the display method of the display. You can find the relevant information to see
_ 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 */horizontal visible area
_ U32 vsync_len;/* length of vertical sync */vertical visible area
_ U32 sync;/* See fb_sync _**/
_ U32 vmode;/* See fb_vmode _**/
_ U32 reserved [6];/* reserved for future compatibility */slave-Future Development
};

2) fb_fix_screeninfon
This structure is created after the video card is set mode. It describes the properties of the display card and cannot be modified during system operation. For example, the starting address of framebuffer memory. It depends on the set mode. When a mode is set, the memory information is provided by the display card hardware, and the memory location and other information cannot be modified.

Struct fb_fix_screeninfo {
Char ID [16];/* identification string eg "TT builtin" */ID
Unsigned long smem_start;/* Start of Frame Buffer mem */memory start
/* (Physical address) */physical address
_ U32 smem_len;/* length of Frame Buffer mem */memory size
_ U32 type;/* See fb_type _**/
_ U32 type_aux;/* interleave for interleaved planes */Insert region?
_ U32 visual;/* See fb_visual _**/
_ 2010xpanstep;/* zero if no hardware panning */Zero if no hardware device exists
_ 2010ypanstep;/* zero if no hardware panning */
_ 2010ywrapstep;/* zero if no hardware ywrap */
_ U32 line_length;/* length of a line in bytes */byte representation of a row
Unsigned long mmio_start;/* Start of memory mapped I/O */memory ing I/O start
/* (Physical address )*/
_ U32 mmio_len;/* length of memory mapped I/O */I/O size
_ U32 accel;/* type of acceleration available */available acceleration types
_ 2010reserved [3];/* reserved for future compatibility */
};

3) fb_cmap
Describes the color ing information unrelated to the device. You can use fbiogetcmap and fbioputcmap
Corresponding IOCTL operation setting or obtaining color ing information.

Struct fb_cmap {
_ U32 start;/* First entry */first entry
_ U32 Len;/* number of entries */entry number
_ 2010* red;/* red values */red
_ 2010* green;
_ 2010* blue;
_ 2010* Transp;/* Transparency, can be null */transparent, can be zero
};

4) fb_info
Defines the current status of the video card. The fb_info structure is only visible in the kernel. In this structure, there is an fb_ops pointer,
Point to the function set required to drive the device.

Struct fb_info {
Char modename [40];/* default video mode */default video card type
Kdev_t node;
Int flags;
Int open;/* has this been open already? */Has it been opened?
# Define fbinfo_flag_module 1/* low-level driver is a module */
Struct fb_var_screeninfo var;/* Current Var */current video information
Struct fb_fix_screeninfo fix;/* Current fix */corrected information
Struct fb_monspecs monspecs;/* Current monitor specs */current display mode
Struct fb_cmap cmap;/* Current cmap */current priority
Struct fb_ops * fbops;
Char * screen_base;/* virtual address */physical base address
Struct display * disp;/* Initial DISPLAY variable */Initialization
Struct vc_data * display_fg;/* console visible on this display */
Char fontname [40];/* default font name */default font
Devfs_handle_t devfs_handle;/* devfs handle for new name */
Devfs_handle_t devfs_lhandle;/* devfs handle for compat. symlink */compatible
INT (* changevar) (INT);/* Tell console VaR has changed */
Tell the console that the variable has been modified
INT (* switch_con) (INT, struct fb_info *);
/* Tell FB to switch between Les */tell FB to select Les
INT (* updatevar) (INT, struct fb_info *);
/* Tell FB to update the vars */notify FB to update the variable
Void (* blank) (INT, struct fb_info *);/* Tell FB to (un) blank the screen
*/Tell FB to use the black/white mode (or not black)
/* Arg = 0: unblank */ARG = 0 in black/white Mode
/* Arg> 0: Vesa level (arg-1) */Arg> 0 select VESA Mode
Void * pseudo _ palette;/* fake palette of 16 colors and
The cursor's color for non
Palette mode */correction palette
/* From here on everything is Device Dependent */can be used now
Void * par;
};

5) struct fb_ops
The user application can use the ioctl () System Call to operate the device. This structure uses these operations that support IOCTL.

Struct fb_ops {
/* Open/release and usage Marking */
Struct module * owner;
INT (* fb_open) (struct fb_info * info, int user );
INT (* fb_release) (struct fb_info * info, int user );
/* Get non settable parameters */
INT (* fb_get_fix) (struct fb_fix_screeninfo * Fix, int con,
Struct fb_info * info );
/* Get settable parameters */
INT (* fb_get_var) (struct fb_var_screeninfo * var, int con,
Struct fb_info * info );
/* Set settable parameters */
INT (* fb_set_var) (struct fb_var_screeninfo * var, int con,
Struct fb_info * info );
/* Get colormap */
INT (* fb_get_cmap) (struct fb_cmap * cmap, int kspc, int con,
Struct fb_info * info );
/* Set colormap */
INT (* fb_set_cmap) (struct fb_cmap * cmap, int kspc, int con,
Struct fb_info * info );
/* Pan display (optional )*/
INT (* fb_pan_display) (struct fb_var_screeninfo * var, int con,
Struct fb_info * info );
/* Perform FB specific IOCTL (optional )*/
INT (* fb_ioctl) (struct inode * inode, struct file * file, unsigned int cmd,
Unsigned long Arg, int con, struct fb_info * info );
/* Perform FB specific MMAP */
INT (* fb_mmap) (struct fb_info * info, struct file * file, struct
Vm_area_struct * VMA );
/* Switch to/from raster image mode */
INT (* fb_rasterimg) (struct fb_info * info, int start );
};

6) structure Map
Struct fb_info_gen | struct fb_info | fb_var_screeninfo
| Fb_fix_screeninfo
| Fb_cmap
| Modename [40]
| Fb_ops --- | ---> ops on VaR
|... | Fb_open
| Fb_release
| Fb_ioctl
| Fb_mmap
| Struct fbgen_hwswitch

\ ----- |-> Detect
| Encode_fix
| Encode_var
| Decode_fix
| Decode_var
| Get_var
| Set_var
| Getcolreg
| Setcolreg
| Pan_display
| Blank
| Set_disp

[It is a little difficult to orchestrate. The first vertical line in the first line is aligned with the first vertical line below, and the second vertical line in the first line is aligned with the second column below.]
This structure fbgen_hwswitch abstracts hardware operations. Although it is not necessary, it is sometimes useful.

2. fbmem. c
Fbmem. c
It is in the center of the framebuffer Device Driver technology. it provides system calls for upper-layer applications and interfaces for specific hardware drivers at the next layer. These underlying hardware drivers need to use these interfaces to register themselves with the system kernel.
Fbmem. C provides common interfaces for all device drivers that support framebuffer to avoid repeated operations.

1) global variables

Struct fb_info * registered_fb [fb_max];
Int num_registered_fb;

These two variables record all instances of the fb_info structure, fb_info
Structure description the current status of the video card. fb_info for all devices
The structure is stored in this array. When a framebuffer Device Driver registers itself with the system, its corresponding fb_info
Structure will be added to this structure, and num_registered_fb will automatically add 1.

Static struct {
Const char * Name;
INT (* init) (void );
INT (* setup) (void );
} Fb_drivers [] _ initdata = {....};

If the framebuffer device is statically linked to the kernel, its corresponding entry will be added to this table; if it is dynamically loaded, that is, using insmod/rmmod, you do not need to care about this table.

Static struct file_operations fb_ops = {
Owner: this_module,
Read: fb_read,
Write: fb_write,
IOCTL: fb_ioctl,
MMAP: fb_mmap,
Open: fb_open,
Release: fb_release
};
This is an interface provided to the application.

2) fbmem. c implements the following functions.

Register_framebuffer (struct fb_info * fb_info );
Unregister_framebuffer (struct fb_info * fb_info );

These two interfaces are provided to the underlying framebuffer device drivers. The device drivers use these two functions to register or deregister themselves with the system. All you need to do for the underlying device driver is to fill in the fb_info structure and then register or deregister it with the system.

(2) An LCD display chip driver instance
With skeleton LCD
For example, the controller driver contains a/FB/skeleton. c framebuffer driver in Linux.
Fb_info structure, and register/deregister yourself. Device Drivers provide system calling interfaces to user programs. Therefore, we need to implement underlying hardware operations and define file_operations.
Structure to provide the system call interface, so as to achieve more effective LCD controller driver.

1) Allocate video memory in the system memory
In the fbmem. c file, we can see that file_operations
The open () and release () operations in the structure do not require the underlying support, but read (), write (), and
The MMAP () operation requires the support of the Function fb_get_fix (). Therefore, you need to implement the function fb_get_fix () again (). In addition, you also need to allocate the video memory space in the system memory. Most LCD controllers do not have their own video memory space. The initial address and length of the allocated address space will be filled in fb_fix_screeninfo.
In the smem_start and smem_len variables of the structure, the allocated space must be physically consecutive.

2) Implement functions in fb_ops
User applications call IOCTL () to operate hardware, fb_ops
The functions in are used to support these operations. (Note: fb_ops structure and file_operations
With different structures, fb_ops is the abstraction of underlying operations, while file_operations is an interface provided for upper-layer systems to call.
The IOCTL () system call is implemented in the file fbmem. C. Through observation, we can find that the ioctl () command and fb_ops's
Function relationships:
Fbioget_vscreeninfo fb_get_var
Fbioput_vscreeninfo fb_set_var
Fbioget_fscreeninfo fb_get_fix
Fbioputcmap fb_set_cmap
Fbiogetcmap fb_get_cmap
Fbiopan_display fb_pan_display

If fb_xxx_xxx is defined
The user program can use the ioctl () Operation of the fbioxxxx macro to operate the hardware.

The Linux/Drivers/Video/fbgen. c file or other device drivers in the Linux/Drivers/video directory is a good reference. Among all these functions, fb_set_var () is the most important. It is used to set the mode and other attributes of the display card. The following describes the execution steps of the function fb_set_var:

1) check whether the mode must be set
2) set the Mode

3) set color ing

4) reset the registers of the LCD controller according to the previous settings.

Step 4 shows where the underlying operations are stored. After the video memory is allocated in the system memory, the starting address and length of the video memory will be set
In the registers of the LCD controller (usually through fb_set_var ()
Function), the content in the video memory will be automatically output to the screen by the LCD controller. On the other hand, the user program maps the display to the user process address space through the MMAP () function, and all data sent by the user process to the ing space will be displayed on the LCD display.

Iii. Application of framebuffer

(1) example of using framebuffer
Framebuffer is mainly implemented according to the VESA standard, so it can only implement the simplest functions.
Due to kernel problems, framebuffer is not allowed to modify the display mode after the system is up. (As if many people want to do this, this is not allowed. Of course, if you write your own driver, it can be implemented ).
The operations on framebuffer directly affect the output of all the consoles on the local machine, including the graphic interface of xwin.
In struct fb_info, char fontname [40];/* default font name */default font
In this way, we can implement the display culture. Is it true that Linux is the way it is made ??

Well, now we can start to implement direct screen writing:

1. Open a framebuffer device.

2. Map the physical memory space of the video card to the user space through MMAP calls.

3. Write memory directly.

/********************************
File Name: fbtools. h
*/

# Ifndef _ fbtools_h _
# DEFINE _ fbtools_h _
# Include <Linux/FB. h>
// A framebuffer device structure;
Typedef struct fbdev {
Int FB;
Unsigned long fb_mem_offset;
Unsigned long fb_mem;
Struct fb_fix_screeninfo fb_fix;
Struct fb_var_screeninfo fb_var;
Char Dev [20];
} Fbdev, * pfbdev;

// Open & init A Frame Buffer
// To use this function,
// You must set fbdev. Dev = "/dev/fb0"
// Or "/dev/fbx"
// It's your frame buffer.
Int fb_open (pfbdev );

// Close a frame buffer
Int fb_close (pfbdev );

// Get display depth
Int get_display_depth (pfbdev );

// Full screen clear
Void fb_memset (void * ADDR, int C, size_t Len );