Problems with 89c6410 double framebuffer in Android

Problems in the Android system During the process of porting the Android system to, it is found that the screen will flash when you drag the taskbar and enter information on the soft keyboard, similar to the insufficient flushing rate. I always think that the reason is that my porting system does not implement 2D acceleration functions such as copybit, resulting in insufficient filling speed. Yesterday, when debugging the dual framebuffer, we found that the problem may be the exchange of the dual framebuffer. Android uses the double framebuffer mechanism. front display, back filling, and frontend and backend interaction are particularly important. Open the debug macro of the Samsung driver and you will find that the system (Android 1.5) continuously calls the following functions of the display driver after EGL initialization to implement buffer exchange: S3cfb_check_var () S3cfb_activate_var () Pan_display () After I opened the printk information of debug, I found a very interesting situation. The so-called flickering phenomenon is gone now, at least I can't see it. Printk will reduce the speed of driver calling, will it cause a problem with the display driver? The article patch framebuffer driver with double-buffering to support Android's page-flipping also mentions that dual buffer drivers cause constant LCD switching. So we found the s3cfb_activate_var () function, which overwrites the LCD register. It should be a short time to rewrite this register, resulting in problems. The temporary solution is to add mdelay (5) latency after this function, but it will lead to lower efficiency. A better solution is to modify the driver or android middle layer call code, this requires tracking of Android UI-related code, to be continued. Solution to the display problem of the two framebuffers In the 2.1/System of Android   In the previous article, problems with 89c6410 double framebuffer in Android found the screen flash problem that occurs when the Android system processes the dual framebuffer driver of the Samsung cloud6410 processor. After analyzing the cupcake Code provided by Samsung in the past two days, we finally found a solution. After Android, Google abstracted the EGL display part of framebuffer into a Hal module-gralloc The swapbuffer used in cupcake is also moved to the framebuffer. cpp file under gralloc. The specific function is changed to fb_post: Static int fb_post (struct framebuffer_device_t * Dev, buffer_handle_t buffer) { If (private_handle_t: Validate (buffer) <0) Return-einval; Fb_context_t * CTX = (fb_context_t *) Dev; Private_handle_t const * HND = reinterpret_cast <private_handle_t const *> (buffer ); Private_module_t * m = reinterpret_cast <private_module_t *> (Dev-> common. Module ); If (m-> currentbuffer ){ M-> base. Unlock (& M-> base, M-> currentbuffer ); M-> currentbuffer = 0; } If (HND-> flags & private_handle_t: priv_flags_framebuffer ){ M-> base. Lock (& M-> base, buffer, Private_module_t: priv_usage_locked_for_post, 0, 0, M-> info. xres, M-> info. yres, null ); Const size_t offset = HND-> base-m-> framebuffer-> base; M-> info. Activate = fb_activate_vbl; M-> info. yoffset = offset/m-> finfo. line_length; If (IOCTL (m-> framebuffer-> FD, fbioput_vscreeninfo, & M-> info) =-1 ){ LogE ("fbioput_vscreeninfo failed "); M-> base. Unlock (& M-> base, buffer ); Return-errno; } M-> currentbuffer = buffer; } Else { // If we can't do the page_flip, just copy the buffer to the front // Fixme: Use copybit Hal instead of memcpy Void * fb_vaddr; Void * buffer_vaddr; M-> base. Lock (& M-> base, M-> framebuffer, Gralloc_usage_sw_write_rarely, 0, 0, M-> info. xres, M-> info. yres, & Fb_vaddr ); M-> base. Lock (& M-> base, buffer, Gralloc_usage_sw_read_rarely, 0, 0, M-> info. xres, M-> info. yres, & Buffer_vaddr ); Memcpy (fb_vaddr, buffer_vaddr, M-> finfo. line_length * m-> info. yres ); M-> base. Unlock (& M-> base, buffer ); M-> base. Unlock (& M-> base, M-> framebuffer ); } Return 0; } ========================================================== ==================================== The function name has changed, but the implementation method has changed. Instead of directly pasting swap, the function uses the time interval for post. However, the underlying processing method remains unchanged.Fbioput_vscreeninfo. Similarly, use pan_display to modify the settings. If (IOCTL (m-> framebuffer-> FD, fbiopan_display, & M-> info) <0) { LogE ("% s: fbiopan_display fail (% s)", _ FUNC __, strerror (errno )); Return 0; } Unsigned int CRTC = 0; If (IOCTL (m-> framebuffer-> FD, fbio_waitforvsync, & CRTC) <0 ){ // S3cfb_wait_for_vsync-> wait_event_interruptible_timeout LogE ("% s: fbio_waitforvsync fail (% s)", _ FUNC __, strerror (errno )); Return 0; } /* If (IOCTL (m-> framebuffer-> FD, fbioput_vscreeninfo, & M-> info) =-1) { LogE ("fbioput_vscreeninfo failed "); M-> base. Unlock (& M-> base, buffer ); Return-errno; } */   ========================================================== ====================================== So far, the problem of display and 2D acceleration that plagued me for several months has finally been solved. The current conclusion is that the 2D Acceleration Engine copybit in Android does not play a significant role in Ui acceleration. Rockie Cheng