FrameBuffer in Android is not as intuitive as in other GUI, a more abstract level, plus the GUI is updated by OpenGLES to do. So make it difficult to figure out the whole process GUI updated recently to prepare a script, so it took some of them to study, do some notes here for your reference, source code is based on Qualcomm platform, these codes can be downloaded online.
FrameBuffer relevant components as shown below:
Pictures posted, however, go to the original address to view http://www.linuxgraphics.cn/android/framebuffer_arch.html
- SurfaceFlinger is a service primarily responsible for the synthesis of each window Surface, and then displayed on the FrameBuffer by OpenGLES. SurfaceFlinger itself is more important and more complex, specially after write it.
- DisplayHardware abstraction is a display device, comprising FrameBuffer and Overlay. It loads plug-ins FrameBuffer and Overlay, and initialize OpenGLES:
mNativeWindow = new FramebufferNativeWindow(); framebuffer_device_t const * fbDev = mNativeWindow->getDevice(); if (hw_get_module(OVERLAY_HARDWARE_MODULE_ID, &module) == 0) { overlay_control_open(module, &mOverlayEngine); } surface = eglCreateWindowSurface(display, config, mNativeWindow.get(), NULL); eglMakeCurrent(display, surface, surface, context);
- FramebufferNativeWindow framebuffer is abstract, it is responsible for loading libgralloc, and open the framebuffer device. FramebufferNativeWindow not directly use the framebuffer, but their own created two Buffer:
- queueBuffer responsible for displaying a Buffer to the screen, it calls fb-> post to display.
- dequeueBuffer get a free Buffer, used to draw in the background.
These two functions are transferred from the eglSwapBuffers over, transferred to:
egl_window_surface_v2_t::swapBuffers： nativeWindow->queueBuffer(nativeWindow, buffer); nativeWindow->dequeueBuffer(nativeWindow, &buffer);
- msm7k / liboverlay achieve the Overlay with other platforms is different, Overlay on a platform is not highpass framebuffer device, and implemented by the ioctl fb0, the ioctl divided into two types of operations:
OverlayControlChannel used to set parameters, such as the installation position of the Overlay, width and height:
mNativeWindow = new FramebufferNativeWindow(); framebuffer_device_t const * fbDev = mNativeWindow->getDevice(); if (hw_get_module(OVERLAY_HARDWARE_MODULE_ID, &module) == 0) { overlay_control_open(module, &mOverlayEngine); } surface = eglCreateWindowSurface(display, config, mNativeWindow.get(), NULL); eglMakeCurrent(display, surface, surface, context);
- FramebufferNativeWindow framebuffer is abstract, it is responsible for loading libgralloc, and open the framebuffer device. FramebufferNativeWindow not directly use the framebuffer, but their own created two Buffer:
- queueBuffer responsible for displaying a Buffer to the screen, it calls fb-> post to display.
- dequeueBuffer get a free Buffer, used to draw in the background.
These two functions are transferred from the eglSwapBuffers over, transferred to:
egl_window_surface_v2_t::swapBuffers： nativeWindow->queueBuffer(nativeWindow, buffer); nativeWindow->dequeueBuffer(nativeWindow, &buffer);
- msm7k / liboverlay achieve the Overlay with other platforms is different, Overlay on a platform is not highpass framebuffer device, and implemented by the ioctl fb0, the ioctl divided into two types of operations:
OverlayControlChannel used to set parameters, such as the installation position of the Overlay, width and height:
bool OverlayControlChannel::setPosition(int x, int y, uint32_t w, uint32_t h) {
ov.dst_rect.x = x;
ov.dst_rect.y = y;
ov.dst_rect.w = w;
ov.dst_rect.h = h;
ioctl(mFD, MSMFB_OVERLAY_SET, &ov);
}
OverlayDataChannel for displaying Overlay, the most important function is to queueBuffer:
bool OverlayDataChannel::queueBuffer(uint32_t offset) { mOvData.data.offset = offset; ioctl(mFD, MSMFB_OVERLAY_PLAY, odPtr)) }
- msm7k / libgralloc is a cache abstraction, including general and the Surface Buffer framebuffer.
framebuffer only / dev / graphic / fb0 packaging, Surface of Buffer it is / dev / pmem, ashmem and GPU memory (msm_hw3dm) packaging, which aims mainly to facilitate hardware acceleration, since DMA transfer using the physical address, memory requirements continuous in physical address.
- msm7k / libcopybit 2D acceleration library which is mainly responsible for Surface tension, rotation and synthesis operations. It is implemented in two ways:
- copybit.cpp: Based fb0 of ioctl (MSMFB_BLIT) of.
- copybit_c2d.cpp: achieve kgsl based only on the packaging of libC2D2.so, libC2D2.so should not be open source.
- Pmem
- misc / pmem.c: physical memory management interface, algorithms and user space.
- board-msm7x27.c define a default size of physical memory:
#define MSM_PMEM_MDP_SIZE 0x1B76000 #define MSM_PMEM_ADSP_SIZE 0xB71000 #define MSM_PMEM_AUDIO_SIZE 0x5B000 #define MSM_FB_SIZE 0x177000 #define MSM_GPU_PHYS_SIZE SZ_2M #define PMEM_KERNEL_EBI1_SIZE 0x1C000
msm_msm7x2x_allocate_memory_regions allocate memory for several large pieces to make a secondary allocation to pmem.
- KGSL
Kernel Graphics the System Layer (KGSL), 3D graphics acceleration driver, the source drivers / gpu / msm directory, which is the GPU packaging, to provide an abstract interface OpenGLES 2.0.
- msm_hw3dm
I did not find this the relevant code in the kernel.
- msm_fb
msm_fb.c: framebuffer, overlay and blit user interface.
mdp_dma.c: packaging specific display device, providing two ways framebuffer update:
mdp_refresh_screen: regularly updated.
mdp_dma_pan_update: automatic updates via pan display.
mdp_dma_lcdc.c: for the LCD display device to achieve, mdp_lcdc_update with framebuffer update
Reproduced in: https: //my.oschina.net/u/920274/blog/3059010