We have a custom board using Colibri iMX8DX module which connects over 24bit RGB through a LVDS transmitter to a display. The display has a resolution of 1280x800px.
I managed to adopt the device-tree and I am really sure the timing for the display is correct.
When I have static display content (nothing changes), the image is stable. As soon as there is something dynamic (like having a clock changing every second) the image is flickering. The boot screen is also shown correctly without any flickering. My application is using qt5 with wayland-egl platform. Cinematic-experience demo application shows the same behavior.
Furthermore I used the eval-board to connect a VGA display.
By applying different device-tree overlays, I changed display resolution:
At VGA resolution - my application doesn’t show any flickering effects.
At FullHD resolution - application and even the boot screen show those errors.
I wonder if it is related to framebuffer memory being too small - but I don’t know how to change it.
Same display works on a similar customized board with iMX6.
I am only having problems with the colors on the evaluation board because our system uses 24bpp RGB interface which is not supported on colibri evaluation board.
Our custom hardware (carrier board + display) doesn’t have issues with the colors - see first video.
My only problem is the flickering. Could this be related to framebuffer size (see original question)?
Thanks for the detailed description of the problem.
Unfortunately, I’ve to inform you that we are aware of the display flickering issue persisting on Colibri iMX8X V1.0D version using a combination of certain resolutions and GPU operations. The team is working on it to find a fix.
In the meantime, you could try a workaround by setting use-g2d=0 in /etc/xdg/weston/weston.ini file and see if that solves the issue.
Maybe here is some more information regarding configuration of the system through the device tree.
My Yocto build patches the device-tree file for eval board and defines the display directly here:
Furthermore I configure the pinmux to map the higher 6 rgb pins to lcd interface (but I don’t think the pin mapping might correspond with this issue).
Could there be any issues with the device tree fragments - especially with the data-mapping?
Is this issue related to Weston / Wayland or Framebuffer? Perhaps my Qt application can use EGLFS without Wayland?
From the best of my knowledge about this issue, I can tell you that this issue seems to be caused by the use of GPU operations (or the lower level OpenGL libraries). Also, there seems to be a corruption in the Framebuffer when the problem appears. We were able to reproduce the issue by using glmark2-es2-wayland. I think it’s worth a try to run the application without Wayland and see if it solves the issue.
Your device tree fragment looks good to me and in my opinion, it has nothing to do with the display flickering.
I will definitely update you here as soon as the team has found a fix to this issue.
I tried two things - first I added EGLFS to qt by having a qtbase_git.bbappend file with "PACKAGECONFIG_append = "eglfs "". This could be built but I wasn’t able to start my app with -platform eglfs. I stopped the weston service and tried to start my application but I always get “could not open egl display” error.
Then I tried a complete new build with DISTRO_FEATURES_remove = " wayland x11 ". But without wayland I don’t have a provider for libgles2: imx-gpu-viv PROVIDES virtual/libgles2 but was skipped: missing required distro feature 'wayland' (not in DISTRO_FEATURES)
Is it possible to run OpenGL on iMX8 without having Wayland enabled / running?
I managed to solve my issue (somehow by chance) because I applied a wrong device-tree overlay colibri-imx8x_parallel-rgb-lvds_overlay.dtbo instead of colibri-imx8x_parallel-rgb_overlay.dtbo .
The main difference between is that the first one uses:
&display_lcdif {
status = "okay";
}
whereas the second one (the one that I had been used before) has:
&adma_lcdif {
status = "okay";
}
Surprisingly after switching completely to the display_lcdif node and correctly applying the 24bpp settings and the pinmux, everything worked well.
For me it looks like there is some issues with the driver used by the adma_lcdif node when having a higher resolution together with 24bpp RGB format.