24-bit panel only displaying 16-bit colour on iMX8QM


I’m using an LVDS panel with my Apalis iMX8QM V1.0B with linux-toradex-5.4-2.3.x and the Toradex 5.x.y BSP. I’ve configured the LVDS panel in the /arch/arm64/dts/freescale/imx8qm-apalis-eval.dts file, and included the resulting patch in my Yocto custom layer. The pertinent sections of the .dts file are shown below:

&panel_lvds {
        status = "okay";
       	compatible = "panel-lvds";
       	backlight = <&backlight>;
       	data-mapping = "vesa-24";
       	width-mm = <152>;
       	height-mm = <91>;

       	panel-timing {
               	clock-frequency = <33200000>;
               	hactive = <800>;
               	vactive = <480>;
               	hfront-porch = <24>;
               	hback-porch = <96>;
               	hsync-len = <72>;
               	vfront-porch = <3>;
               	vback-porch = <10>;
               	vsync-len = <7>;

               	hsync-active = <0>;
               	vsync-active = <0>;
               	pixelclk-active = <0>;

       	port {
               	panel_lvds_in: endpoint {
                       	remote-endpoint = <&lvds_out>;

&ldb2 {
        status = "okay";

        lvds-channel@0 {
                fsl,data-mapping = "spwg";
                fsl,data-width = <24>;
                status = "okay";

                port@1 {
                        reg = <1>;

                        lvds_out: endpoint {
                                remote-endpoint = <&panel_lvds_in>;

&ldb2_phy {
         status = "okay";

With the above device tree configuration, the display only seems to work in 16-bit mode. This has been confirmed by checking the value of the bits_per_pixel file in /sys/class/graphics/fb0/bits_per_pixel.

This is particularly evident in the severe colour banding I see when using the display. For the purposes of illustrating this point, I setup a small Qt application which just displays a gradient (from red to white) across a 480x480 pixel square:

Using the Qt QSG_INFO environment variable, I can see that the R/G/B/A buffers (as used by Qt) are set to 4 4 4 0, not the 8 8 8 8 (or 8 8 8 0) I’d expect for the configured 24/32-bit panel. Note that I can use the QT_QPA_EGLFS_FORCE888 Qt environment variable, which forces RGB888 mode, and while it drastically improves the colour banding issue, it doesn’t resolve the underlying issue that my configuration appears to be wrong. If the configuration was correct, the default bits per pixel would be correctly set to 24/32, and manual intervention within Qt wouldn’t be required.

Is there anything obviously wrong with my device tree configuration? Are there any additional ‘video’ or ‘vidargs’ flags I should be using from the u-boot command line (the Toradex article ‘Display Output, Resolution and Timings (Linux)’ suggests not, stating that all iMX8 display configuration should be performed in the device tree). I’ll also mention that trying to change the fb0 mode or bits_per_pixel (i.e. echo 24 > /sys/class/graphics/fb0/bits_per_pixel) results in a ‘echo: write error: Invalid argument’ error.

One final note: I’ve used this exact display previously on an iMX6 project, and was able to configure and use it in 24/32-bit mode. As such, I don’t believe this is a hardware issue, but an issue of device tree (or other) configuration.


The Apalis iMX8QM V1.0B is an Early Access Release sample and not supported by current software. Please order an Apalis iMX8QM V1.1C

Hi @alex.tx

Thanks for the prompt reply! I’m aware that this is an early version, however is there any reason why it would exhibit this issue? The only errata I can see which has some relevance is HAR-4399, but the issue described doesn’t align with mine.

You can try to play wit data-mapping and data-width parameters.

What is you display model (datasheet)? What carrier board you are using? How exactly your display wired to carrier board.

The display datasheet is here. I have both BITSEL and SELLVDS tied low, which puts it in 8-bit, VESA 24 mode (per the diagram at the bottom of page 12 of the datasheet).

The display is connected to a custom carrier board via a 30-pin SMT connector. I’ve used the same connector and carrier board design as with the previous iMX6 design which didn’t exhibit this issue.

you can display this image

on your screen by the following command. Our multimedia image has GStreamer packages installed.

~# gst-launch-1.0 filesrc location=RGB_Banner.jpg ! jpegdec ! imagefreeze ! autovideosink

A smooth gradient will be observed.

Thanks @benjamin.tx

I’ve just given that a go, but I get the following gstreamer errors:

Setting pipeline to PAUSED …
Pipeline is PREROLLING …
ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0: Internal data stream error.
Additional debug info:
…/git/libs/gst/base/gstbasesrc.c(3072): gst_base_src_loop (): /GstPipeline:pipeline0/GstFileSrc:filesrc0:
streaming stopped, reason not-negotiated (-4)
ERROR: pipeline doesn’t want to preroll.
Setting pipeline to NULL …
Freeing pipeline …

Hi @jars121 , what is the BSP version on you Apalis iMX8 SoM? I tested it with Linux BSP v5.5.0.

Hi @benjamin.tx

I’m not exactly sure of the BSP version (is there an easy way to find this in the build directory?), but I’m using the dunfell-5.x.y branch for OE-Core. I.e.:

repo init -u http://git.toradex.com/toradex-manifest.git -b dunfell-5.x.y -m tdxref/default.xml

Your command should download our latest BSP if you build it recently. You can check it by the following two commands on Apalis iMX8.

uname -a
cat /etc/issue

Thanks for clarifying, the result of uname -a is as follows:

Linux localhost 5.4.161-5.6.0-devel+git.e395d949e46b #1 SMP PREEMPT Thu Jan 27 13:39:54 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

As for the second command, I don’t have a /etc/issue file.

The /etc/issue comes from our default image built by Yocto Project. Could you please check if you build your own rootfs e.g. debian/ubuntu distro? You can also display the gradient image in other ways available on your board. For example, a Qt demo showing the image in full screen. gst-launch-1.0 is just a tool on our image to show the picture. I built a image hours ago and gst-launch-1.0 works well on Apalis iMX8QM V1.1C SoM. Unfortunately, I don’t have a V1.0B SoM on hand.