This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Double render on landscape

Other Parts Discussed in Thread: AM3354, DA8XX

Hi Guys,
Please help.

I've done a semi-custom build for a SoM based on Ti AM3354. All works well except for the landscape display.
I get a very strange "double-render" when the display change to landscape - just after the boot animation.

Please see attache photo.

I looked at changing dpi and investigated the layers in surfaceflinger - the issue seems to be caused by the animation service; but I might be totally wrong.

Any guidance will be greatly appreciated.

Cheers

Louis

  • Hi Louis,
    Could you please reproduce this issue on supported Am335x-based TI platform on the latest JB 4.2.2? Otherwise, it would be challenging for us to support you effectively
  • Good day,


    Apologies for replying so late - we've been debugging and trying to get this issue resolved - no luck ...

    We are using a MYIR-3354 SOM; running Android with a 1280x720 LCD which has a 4 lane MIPI interface; the MIPI Bridge is done using a SSD2828 MIPI Bridge controller.

    Please note that we are using a 16bit colour configuration: RGB565; as the MYIR SOM doesn't support 32bit colour due to IO pin limitations.

    I've re-done a complete new installation, starting with running the TI_Android_JB_4.2.2_DevKit_4.1.1.bin

    Once done, I re-applied the required changes to bring our hardware up.
    This mainly consists of:

    1.) Updated board-am335xevm.c to suit our hardware.

    2.) Changed da8xxx for LCD:

    [9] = {
       /* 1280 x 720 @ 60 Hz */
       .name = "nxp-1280x720@60",
       .width = 720,
       .height = 1280,
       .hfp = 24,
       .hbp = 104,
       .hsw = 8,
       .vfp = 16,
       .vbp = 14,
       .vsw = 2,
       .pxl_clk = 63600000,
       .invert_pxl_clk = 0,
    },

    We set the PLL in the board file to: conf_disp_pll(318000000) - to ensure a very close match to the final pclk


    3.) Added and modified gt9xx touch screen driver.

    4.) Modified u-boot as per MYIR requirements/example.

    5.) Configure android to run our application has home; and remove keyguard and all wallpapers ...


    The kernel boots 100%

    Android starts fine - we are running a custom boot animation, which is perfect - NO TEARING at this point.
    There are no unexpected errors in logcat.

    The EGL / SGX init is as follows:

    D/libEGL (   76): loaded /system/lib/egl/libEGL_POWERVR_SGX530_125.so

    D/libEGL (   76): loaded /system/lib/egl/libGLESv1_CM_POWERVR_SGX530_125.so

    D/libEGL (   76): loaded /system/lib/egl/libGLESv2_POWERVR_SGX530_125.so

    E/SurfaceFlinger(   76): hwcomposer module not found

    W/SurfaceFlinger(   76): getting VSYNC period from fb HAL: 17658172

    W/SurfaceFlinger(   76): no suitable EGLConfig found, trying without EGL_FRAMEBUFFER_TARGET_ANDROID

    W/SurfaceFlinger(   76): no suitable EGLConfig found, trying without EGL_RECORDABLE_ANDROID

    W/SurfaceFlinger(   76): no suitable EGLConfig found, trying with 16-bit color allowed

    I/SurfaceFlinger(   76): EGL informations:

    I/SurfaceFlinger(   76): vendor   : Android

    I/SurfaceFlinger(   76): version   : 1.4 Android META-EGL

    I/SurfaceFlinger(   76): extensions: EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_fence_sync EGL_ANDROID_image_native_buffer

    I/SurfaceFlinger(   76): Client API: OpenGL_ES

    I/SurfaceFlinger(   76): EGLSurface: 5-6-5-0, config=0x8

    I/SurfaceFlinger(   76): OpenGL ES informations:

    I/SurfaceFlinger(   76): vendor   : Imagination Technologies

    I/SurfaceFlinger(   76): renderer : PowerVR SGX 530

    I/SurfaceFlinger(   76): version   : OpenGL ES-CM 1.1

    I/SurfaceFlinger(   76): extensions: GL_EXT_debug_marker GL_OES_byte_coordinates GL_OES_fixed_point GL_OES_single_precision GL_OES_matrix_get GL_OES_read_format GL_OES_compressed_paletted_texture GL_OES_point_sprite GL_OES_point_size_array GL_OES_matrix_palette GL_OES_draw_texture GL_OES_query_matrix GL_OES_texture_env_crossbar GL_OES_texture_mirrored_repeat GL_OES_texture_cube_map GL_OES_blend_subtract GL_OES_blend_func_separate GL_OES_blend_equation_separate GL_OES_stencil_wrap GL_OES_extended_matrix_palette GL_OES_framebuffer_object GL_OES_rgb8_rgba8 GL_OES_depth24 GL_OES_stencil8 GL_OES_compressed_ETC1_RGB8_texture GL_OES_mapbuffer GL_OES_EGL_image GL_OES_EGL_image_external GL_EXT_multi_draw_arrays GL_OES_required_internalformat GL_IMG_read_format GL_IMG_texture_compression_pvrtc GL_IMG_texture_format_BGRA8888 GL_EXT_texture_format_BGRA8888 GL_OES_egl_sync GL_IMG_vertex_array_object GL_APPLE_texture_2D_limited_npot

    I/SurfaceFlinger(   76): GL_MAX_TEXTURE_SIZE = 2048

    I/SurfaceFlinger(   76): GL_MAX_VIEWPORT_DIMS = 2048 x 2048

    D/SurfaceFlinger(   76): Screen acquired, type=0 flinger=0x418ec318



    Our major issue is that the application starts off ok, but you get the tearing effect within a couple of seconds.
    Please see the attached photos.

    We've done extensive debugging and tracing.
    SurfaceFlinger posts the final framebuffer before the application goes idle.
    The screen is fine; and the tearing starts around 1 second after the application is idle.
    You can then move frames/fragments of the application around and get the screen to be perfect; but the tearing starts again after around 1 second.

    There is no hwcomposer and the frame buffer seems to be managed by gralloc.omap3.so - which we don't have the source code for.
    Basically the default setup.

    We confirmed that the patch for the documented tearing issue in da8xx has been implemented in TI_Android_JB_4.2.2_DevKit_4.1.1.
     

    We compile with OMAPES=4.x.

    It doesn't seem to be an Android issue - as SurfaceFlinger and associated services are idle when the tearing takes place.

    Also - if I kill SurfaceFlinger, "Android" restarts and the bootanimation then has the same tearing.

    We've also enabled the keyguard again to see an "Android" app instead of our's - same tearing ...


    I will appreciate any assistance, guidance and suggestions.

    We'll continue to investigate the interface between the AM3354 and the MIPI bridge controller.2425.LCDTearing.zip
     

  • We finally resolved the issue.

    There was a configuration mismatch between the AM3354 the SSD2828 and the LCD's internal controller IC.

    Thanks for the input.