Underlying journey-Analysis of the android display driver (framebuffer)

Android has a complete display system. The upper-layer display system provides output devices for system graphics. the Java layer and controls are displayed by the display system. The underlying Display System of Android has a strong relationship with the surface library of Android. The underlying display system provides encapsulation of basic display and output devices. The surface library is based on this display terminal and provides support for multiple layers and effects between layers. The android display system is hierarchical.

Figure 1 Android display hierarchy

In the android display driver, a hardware module named gralloc is located between the libui and the display device driver. This gralloc is used as the hardware abstraction layer of the display system. 2.

Figure 2 Relationship Between gralloc and framebuffer drivers

The gralloc module has the form of a dynamic library placed in/system/lib/HW. Other parts of the system do not connect to this dynamic library, but use dlopen and dlsym to dynamically open and retrieve symbols during running. The gralloc module is a portable hardware abstraction layer. It is an interface between a system and a display device and exists as a hardware module. The Android system usually uses framebuffer as its driver. However, gralloc can also be used without the framebuffer device. In the upper layer, framebuffernativewindows. cpp in the libui library is the main caller of the gralloc module.

Libui is an Integrated Framework library of Android at a local level. It is not only the hub of reality, but also the hub of the entire androidgui system. This library provides some interfaces, which are implemented by other libraries through class inheritance. The caller only needs to call the libui library interface. The libui library contains the color format, EGL window (User display), buttons and event processing, surface (display interface), overlay (display overlay Interface), and camera (camera interface) and so on.

Because Android is based on the Linux operating system, the underlying Display Device Driver of Android is a framebuffer driver. The framebuffer driver is a character device driver. It adopts the "file layer-driver layer" interface mode. The driver layer interface defined for the frame buffer device in Linux is the fb_info structure. At the file level, the user calls the function operation of the file_operations struct, and indirectly calls the function of the fb_ops struct to operate the hardware. When registering an FB device with the kernel, the pointer of struct fb_ops is also registered. When the FB device is enabled, call xxxfb_init () of fb_drivers [] to initialize the device. The device node of the framebuffer driver in the file system is usually/dev/fbx.

The framebuffer device driver is mainly based on three files in the Linux kernel source code:

/Include/Linux/FB. h

/Drivers/Video/fbmem. h

/Driver/Video/xxxfb. c

FB. H mainly defines some struct and macros; fbmem. h implements interfaces for device initialization, uninstallation, and file operations. xxxfb. c implements the entry point function xxxfb_init; xxxfb_setup for the device driver file (such as struct fb_info) that you have added.

One of the most critical data structures of the framebuffer device is the fb_info structure, which includes a complete description of the attributes and operations of the frame buffer device. The structure is defined as follows (include/Linux/FB. h ):

struct fb_info {int node;int flags;struct mutex lock;/* Lock for open/release/ioctl funcs */struct mutex mm_lock;/* Lock for fb_mmap and smem_* fields */struct fb_var_screeninfo var;/* Current var */struct fb_fix_screeninfo fix;/* Current fix */struct fb_monspecs monspecs;/* Current Monitor specs */struct work_struct queue;/* Framebuffer event queue */struct fb_pixmap pixmap;/* Image hardware mapper */struct fb_pixmap sprite;/* Cursor hardware mapper */struct fb_cmap cmap;/* Current cmap */struct list_head modelist;      /* mode list */struct fb_videomode *mode;/* current mode */#ifdef CONFIG_FB_BACKLIGHT/* assigned backlight device *//* set before framebuffer registration,    remove after unregister */struct backlight_device *bl_dev;/* Backlight level curve */struct mutex bl_curve_mutex;u8 bl_curve[FB_BACKLIGHT_LEVELS];#endif#ifdef CONFIG_FB_DEFERRED_IOstruct delayed_work deferred_work;struct fb_deferred_io *fbdefio;#endifstruct fb_ops *fbops;struct device *device;/* This is the parent */struct device *dev;/* This is this fb device */int class_flag;                    /* private sysfs flags */#ifdef CONFIG_FB_TILEBLITTINGstruct fb_tile_ops *tileops;    /* Tile Blitting */#endifchar __iomem *screen_base;/* Virtual address */unsigned long screen_size;/* Amount of ioremapped VRAM or 0 */ void *pseudo_palette;/* Fake palette of 16 colors */ #define FBINFO_STATE_RUNNING0#define FBINFO_STATE_SUSPENDED1u32 state;/* Hardware state i.e suspend */void *fbcon_par;                /* fbcon use-only private area *//* From here on everything is device dependent */void *par;/* we need the PCI or similiar aperture base/size not   smem_start/size as smem_start may just be an object   allocated inside the aperture so may not actually overlap */resource_size_t aperture_base;resource_size_t aperture_size;};

Fbops, a member variable of fb_info, is a pointer to the function for underlying operations. These functions need to be compiled by driver developers.

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);/* For framebuffers with strange non linear layouts or that do not * work with normal memory mapped access */ssize_t (*fb_read)(struct fb_info *info, char __user *buf,   size_t count, loff_t *ppos);ssize_t (*fb_write)(struct fb_info *info, const char __user *buf,    size_t count, loff_t *ppos);/* checks var and eventually tweaks it to something supported, * DO NOT MODIFY PAR */int (*fb_check_var)(struct fb_var_screeninfo *var, struct fb_info *info);/* set the video mode according to info->var */int (*fb_set_par)(struct fb_info *info);/* set color register */int (*fb_setcolreg)(unsigned regno, unsigned red, unsigned green,    unsigned blue, unsigned transp, struct fb_info *info);/* set color registers in batch */int (*fb_setcmap)(struct fb_cmap *cmap, struct fb_info *info);/* blank display */int (*fb_blank)(int blank, struct fb_info *info);/* pan display */int (*fb_pan_display)(struct fb_var_screeninfo *var, struct fb_info *info);/* Draws a rectangle */void (*fb_fillrect) (struct fb_info *info, const struct fb_fillrect *rect);/* Copy data from area to another */void (*fb_copyarea) (struct fb_info *info, const struct fb_copyarea *region);/* Draws a image to the display */void (*fb_imageblit) (struct fb_info *info, const struct fb_image *image);/* Draws cursor */int (*fb_cursor) (struct fb_info *info, struct fb_cursor *cursor);/* Rotates the display */void (*fb_rotate)(struct fb_info *info, int angle);/* wait for blit idle, optional */int (*fb_sync)(struct fb_info *info);/* perform fb specific ioctl (optional) */int (*fb_ioctl)(struct fb_info *info, unsigned int cmd,unsigned long arg);/* Handle 32bit compat ioctl (optional) */int (*fb_compat_ioctl)(struct fb_info *info, unsigned cmd,unsigned long arg);/* perform fb specific mmap */int (*fb_mmap)(struct fb_info *info, struct vm_area_struct *vma);/* save current hardware state */void (*fb_save_state)(struct fb_info *info);/* restore saved state */void (*fb_restore_state)(struct fb_info *info);/* get capability given var */void (*fb_get_caps)(struct fb_info *info, struct fb_blit_caps *caps,    struct fb_var_screeninfo *var);/* teardown any resources to do with this framebuffer */void (*fb_destroy)(struct fb_info *info);};