Wrong Qt-Rendering with platform EGLFS

[michaelwiesent]

I have exactly the same problem as in this thread EGLFS ugly rendering. .

In my case i have a display with 800x480 pixel. EGL renders obviously 1000x480 pixel. The 200 pixel are shifted like in the picture below but when i change the parameter bits_per_pixel from 24 to 32 bit (/sys/class/graphics/fb0/bits_per_pixel) the shift will not be visible on the left side. I will simply not be shown anymore because of the end of the display. The rendering failure still exists.

Which init file do jamesbone mean and where can i find this file?

Here are some pictures from my side to give you a better felling what is happening to my system:

Picture 1: this picture shows the effect like above with visible shift

Picture 2: here we can see the same effect but the pixel depth is changed from 24 to 32 bit

Picture 3: this picture shows the output, when i start the example with linuxfb (but in our project we can´t use linuxfb because we use opengl es 2)

PS: it seems that the eglfs is not interested in the environment variables mentioned here: Qt for Embedded Linux | Qt 5.4

I tested some possible settings but there is no effect to the output. We use Qt 5.3.2 built with yocto in our application.

Also fbset 800 480 800 480 24 only have a effect on the color depth.

Would be perfect if anyone can give some support to me or have some ideas.

Michael

[jamesbone]

It seems that you have settings incorrect of the  EGL native Window, so in your init function of your application you need to check  EGLQuerySurface. To provide the width and height of EGL.

/*get width and height from egl*/ 
        eglQuerySurface(egldisplay, eglsurface, EGL_WIDTH, &w); 
        eglQuerySurface(egldisplay, eglsurface, EGL_HEIGHT, &h); 
       

[michaelwiesent]

Thanks for your response.

I don´t exactly know where to set this settings. In the pictures above i tried to use the standard examples from Qt. It´s the example under examples/widgets/animation/animatedtiles. Therefore I don´t think, that I have to change the code for this examples. It has to work.

I also invested some time in getting into the platform coding and the framebuffer. After this i have a guess but don´t know how or where to fix it. When linuxfb is used there are only the RGB values in the framebuffer. It looks like this

R G B R G B R G B ...

When I use the platform eglfs it seems that there is the color format RGBA so it looks like this

R G B A R G B A R G B A ...

The alpha channel has always the value 0xFF. I checked this with hexdump.

I think that the driver (should be vivante) which is interpreting this data do not know about this RGBA format und interpet it like a RGB format. I tried to set the boot parameters to RGBA32 or RGBA8888 but there was no change. The result could be the following:

framebuffer                              R G B A R G B A R G B A

graphic driver interpretation     R G B R G B R G B R G B

This could be the reason why the image is around 200px larger. The basic width is 800px.

I´m able to cross compile the libqeglfs.so. Therefore I added some debugging information for a better understanding how this plugin works. So I can change anything of this plugin. Can anyone tell me where I can set the color width so that only RGB is set to the framebuffer?

UPDATE:
I think i have to change the configuration of the attribute EGL_BUFFER_SIZE or EGL_NATIVE_VISUAL_TYPE from 32 to 24. Where can i do that?

[michaelwiesent · Accepted solution]

Have some great news i want to share. After some searching i found this link

iMX6QD How to Add 24-bit LVDS Support in Android

Here is exactly described how to solve my problem. I have to change the boot parameter. Here is the important part

... if=RGB24,fbpix=RGB32

These parameters describe that the display need RGB24 while the framebuffer holds data with RGB32. After this change it works perfect. Therefore I don´t have to change the EGLFS platform.

Hope i can help somebody else with this information.

[hardyb]

Thank you for following up. We were addressing this issue on a Wandboard Solo and your fix in the uboot arguments got it for us.