Strange Display Behavior with QT5 EGLFS

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Strange Display Behavior with QT5 EGLFS

Jump to solution
9,459 Views
patrickvogelaar
Contributor II

The board is a custom board based on the imx6DL processeor. The display is a 320x320 (24bit) RGB AMOLED MIPI display (X163QLN01). Yocto krogoth is used with Qt 5.6

I have written a mipi display driver based on the mxcfb_hx8369_wvga.c driver. And everything works fine when the core-image-sato is used (see pictures below). So I guess it cannot be a problem of my display driver.

core_img_sato_default.jpg

Here the display with fb-test executed.

core_img_sato_fb_test.jpg

Now the problem is if I use Qt5 with EGLFS the display/frambuffer seems to be configured the wrong way. The display is not completely filled anymore and it seems that image is reduced to half the width and every second line is displayed beside the other half image.

Below is a picture of the display when fb-test is executed:

custom_img_fb_test.jpg

And another image, were Qt5_CinematicExperience was executed.

custom_img_qt_cinematic.jpg

Here my configurations:

Device Tree:

aliases {
mxcfb0 = &mxcfb1;

    };

mxcfb1: fb@0 {
compatible = "fsl,mxc_sdc_fb";
disp_dev = "mipi_dsi";
interface_pix_fmt = "RGB24";
mode_str ="TRULY-WVGA";
default_bpp = <32>;
int_clk = <0>;
late_init = <0>;
status = "okay";

    };

Bootr parameters:

video=mxcfb0:dev=mipi_dsi,TRULY-WVGA,if=RGB24,fbpix=RGB32

Driver structs:

static struct fb_videomode truly_lcd_modedb[] = {

    {

     "TRULY-WVGA", 57, 320, 320, 80674,

     4, 164,

     18, 100,

     4, 2,

     FB_SYNC_OE_LOW_ACT,

     FB_VMODE_NONINTERLACED,

     0,

    },

};

static struct mipi_lcd_config lcd_config = {

    .virtual_ch        = 0x0,

    .data_lane_num  = X163QLN01_ONE_DATA_LANE,

    .max_phy_clk    = X163QLN01_MAX_DPHY_CLK,

    .dpi_fmt        = 5 //MIPI_RGB888

};

My assumptions are that there are problems width the different color depths of the framebuffer (32) and the display (24) because as you can see in the fb-test pictures the colors are different. I'am trying since three days to get this work with different parameters however without any success.

Could someone please point me in a direction what could be wrong or how to figure out where the problem is. Right now I am out of ideas.

If you need further information just let me know.

Thanks

Patrick

EDIT:

I did some further investigation that may help. Before starting the Qt5_CinematicExperience application I've set some debug environment variables:

export QSG_INFO=1

export QT_LOGGING_RULES=qt.qpa.*=true

export QT_QPA_EGLFS_DEBUG

This is the Output:

qt.qpa.egldeviceintegration: EGL device integration plugin keys: ("eglfs_viv", "eglfs_viv_wl")

qt.qpa.egldeviceintegration: EGL device integration plugin keys (sorted): ("eglfs_viv", "eglfs_viv_wl")

qt.qpa.egldeviceintegration: Trying to load device EGL integration "eglfs_viv"

qt.qpa.egldeviceintegration: Using EGL device integration "eglfs_viv"

QEglFSVivIntegration will set environment variable FB_MULTI_BUFFER=2 to enable double buffering and vsync.

If this is not desired, you can override this via: export QT_EGLFS_IMX6_NO_FB_MULTI_BUFFER=1

Height 320; Width 320

Unable to query physical screen size, defaulting to 100 dpi.

To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters).

qt.qpa.input: evdevkeyboard: Using device discovery

qt.qpa.input: udev device discovery for type QFlags(0x8)

qt.qpa.input: Found matching devices ()

qt.qpa.input: evdevmouse: Using device discovery

qt.qpa.input: udev device discovery for type QFlags(0x1|0x2)

qt.qpa.input: Found matching devices ()

qt.qpa.input: evdevtouch: Using device discovery

qt.qpa.input: udev device discovery for type QFlags(0x2|0x4)

qt.qpa.input: Found matching devices ()

qt.scenegraph.info: threaded render loop

qt.scenegraph.info: Using sg animation driver

qt.scenegraph.info: Animation Driver: using vsync: 17.54 ms

libpng warning: iCCP: known incorrect sRGB profile

libpng warning: iCCP: known incorrect sRGB profile

FSWindow::resetSurface

Created context for format QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 1, profile  0) with config:

    EGL_BUFFER_SIZE: 12

    EGL_ALPHA_SIZE: 0

    EGL_BLUE_SIZE: 4

    EGL_GREEN_SIZE: 4

    EGL_RED_SIZE: 4

    EGL_DEPTH_SIZE: 24

    EGL_STENCIL_SIZE: 8

    EGL_CONFIG_CAVEAT: 12344

    EGL_CONFIG_ID: 5

    EGL_LEVEL: 0

    EGL_MAX_PBUFFER_HEIGHT: 8064

    EGL_MAX_PBUFFER_PIXELS: 65028096

    EGL_MAX_PBUFFER_WIDTH: 8064

    EGL_NATIVE_RENDERABLE: 0

    EGL_NATIVE_VISUAL_ID: 0

    EGL_NATIVE_VISUAL_TYPE: 12344

    EGL_SAMPLES: 0

    EGL_SAMPLE_BUFFERS: 0

    EGL_SURFACE_TYPE: 1285

    EGL_TRANSPARENT_TYPE: 12344

    EGL_TRANSPARENT_BLUE_VALUE: -1

    EGL_TRANSPARENT_GREEN_VALUE: -1

    EGL_TRANSPARENT_RED_VALUE: -1

    EGL_BIND_TO_TEXTURE_RGB: 1

    EGL_BIND_TO_TEXTURE_RGBA: 1

    EGL_MIN_SWAP_INTERVAL: 0

    EGL_MAX_SWAP_INTERVAL: 10

qt.scenegraph.info: Animation Driver: using vsync: 17.54 ms

qt.scenegraph.info: texture atlas dimensions: 512x512

qt.scenegraph.info: R/G/B/A Buffers:    4 4 4 0

qt.scenegraph.info: Depth Buffer:       24

qt.scenegraph.info: Stencil Buffer:     8

qt.scenegraph.info: Samples:            0

qt.scenegraph.info: GL_VENDOR:          Vivante Corporation

qt.scenegraph.info: GL_RENDERER:        Vivante GC880

qt.scenegraph.info: GL_VERSION:         OpenGL ES 3.0 V5.0.11.p8.41671

qt.scenegraph.info: GL_EXTENSIONS:      GL_EXT_read_format_bgra GL_EXT_texture_filter_anisotropic GL_EXT_robustness GL_EXT_texture_type_2_10_10_10_REV GL_OES_depth32 GL_OES_vertex_half_float GL_OES_fragment_precision_high GL_OES_standard_derivatives GL_EXT_blend_minmax  GL_OES_get_program_binary GL_OES_compressed_ETC1_RGB8_texture GL_OES_vertex_type_10_10_10_2 GL_OES_depth_texture GL_EXT_texture_format_BGRA8888 GL_OES_packed_depth_stencil GL_OES_depth24 GL_OES_element_index_uint GL_EXT_multi_draw_arrays GL_OES_texture_npot GL_OES_rgb8_rgba8 GL_OES_mapbuffer GL_VIV_direct_texture GL_OES_vertex_array_object GL_OES_EGL_image GL_EXT_frag_depth GL_OES_EGL_sync GL_OES_required_internalformat GL_OES_compressed_paletted_texture GL_OES_fbo_render_mipmap GL_OES_depth_texture_cube_map GL_EXT_discard_framebuffer GL_EXT_multisampled_render_to_texture GL_OES_surfaceless_context

qt.scenegraph.info: Max Texture Size:  8192

qt.scenegraph.info: Debug context:     false

It seems that Qt uses a color depth of 12bit and gets this from EGL. How can I modify the color settings of EGL?

Thanks Patrick

0 Kudos
1 Solution
3,571 Views
patrickvogelaar
Contributor II

Just a update. The problem was in the initialisation sequence of the mipi display in our own driver. The display worked after a blank. This explains why it worked with X because itseems that X does a blank before start.

View solution in original post

0 Kudos
5 Replies
3,572 Views
patrickvogelaar
Contributor II

Just a update. The problem was in the initialisation sequence of the mipi display in our own driver. The display worked after a blank. This explains why it worked with X because itseems that X does a blank before start.

0 Kudos
3,571 Views
enrico_papi
Contributor II

Hi Patrick,

your post is very useful to us since we are working with the same display model.

Is it possible for you to share the mipi display driver code developed? Thank you.

Regards,

Enrico

0 Kudos
3,571 Views
whoopy
Contributor I

Might be a bit late for you, but I think the following environment variable can force 24bit RGB in QEglFSWindow::resetSurface()

export QT_QPA_EGLFS_FORCE888=1

see Qt for Embedded Linux - docs

3,571 Views
Bio_TICFSL
NXP TechSupport
NXP TechSupport

Hi Patrick,

Looks like pixclock issue, maybe this info can be helpful:

iMX6QD How to Add 24-bit LVDS Support in Android

regards

0 Kudos
3,571 Views
patrickvogelaar
Contributor II

Thanks for the reply. Could you please explain for me to understand how it is possible that in one case the image is shown the correct and in the other way it is shown the wrong way? I'm using the same Kernel and device tree in both cases. Can X11 readjust the timings?

Thanks

Patrick

0 Kudos