LVDS Display Problems ( Red Screen)

Hello, we’re having a display issue with an imx6dl colibri and an LVDS screen with an RGB->LVDS converter like on the carrier board.

The resolution is correct, but the screen is displayed in red . Here’s the overlay, and it’s loaded correctly at startup…

// SPDX-License-Identifier: GPL-2.0-or-later OR MIT

/*
 * Copyright 2022 Toradex
 */

// Enable the parallel RGB interface on the Colibri iMX6 and the
// LVDS transceiver on the Iris v2.0A with a connected capacitive
// touch 10.1" LVDS display.

#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/media/video-interfaces.h>

/dts-v1/;
/plugin/;

/ {
     compatible = "toradex,colibri_imx6dl";
};
 
/* Active le rétroéclairage */
&backlight {
     compatible = "pwm-backlight";
     pwms = <&pwm3 0 50000 0>; /* exemple : PWM3, période 50 000 ns */
     brightness-levels = <0 32 64 96 128 160 192 224 255>;
     default-brightness-level = <8>;
     status = "okay";
};
 
/* Interface LCD principale */
&lcd_display {
    interface-pix-fmt = "RGB24";
    default_bpp = <24>;
    status = "okay";
};
 
/* Configuration du panneau LVDS via DS90C383B */
&panel_dpi {
	compatible = "panel-dpi";
	status = "okay";
    width-mm = <330>;
    height-mm = <210>;
 
	data-mapping = "vesa-24";     /* ou "jeida-24" selon ton convertisseur LVDS */
	bus-width = <24>;
 
     /* Timings LVDS 1024x600 */
     panel-timing {
         clock-frequency = <52000000>;
         hactive = <1024>;
         vactive = <600>;
			hsync-len = <16>;
			hfront-porch = <64>;
			hback-porch = <64>;
			vsync-len = <8>;
			vfront-porch = <8>;
			vback-porch = <8>;
			hsync-active = <0>;
			vsync-active = <0>;
			de-active = <1>;
			pixelclk-active = <0>;
     };
};

&gpio3 {
    lvds-gpio-sodimm81 {
        gpio-hog;
        gpios = <29 GPIO_ACTIVE_HIGH>; /* SODIMM 81 */
        line-name = "LVDS_GPIO_SODIMM_81";
        output-high;
    };
};


&pwm3 {
	status = "okay";
};

One thing that seems abnormal :

cat /sys/class/graphics.fb0/bits_per_pixel
16

Shouldn’t it display 24?
I’ve tried several overlay configurations, but no improvements; the screen remains red.

I am stuck , could you help us ?
Thanks
Seb

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


LVDS Display Issues with Colibri iMX6DL

Based on your description and the red-tinted display output, this appears to be a color mapping configuration issue with your LVDS setup. Let me help you troubleshoot this step by step.

Color Mapping Configuration

The issue is likely related to the LVDS color mapping configuration. According to the Toradex documentation, there are different color mapping standards for LVDS displays (1):

  1. 18-bit LVDS Color Mapping - This is the standardized mapping
  2. 24-bit JEIDA Color Mapping - Compatible with 18-bit interface (also called “24-bit / 18-bit Compatible Color Mapping”)
  3. 24-bit VESA Color Mapping - The most common 24-bit color mapping, but not backward compatible

Troubleshooting Steps

1. Verify Color Mapping Setting

In your overlay, you’re using data-mapping = "vesa-24". Try changing this to the JEIDA format (1):

data-mapping = "jeida-24";

2. Check Bus Width Configuration

The 16-bit framebuffer output you’re seeing suggests a mismatch. Try adjusting your configuration:

&lcd_display {
    interface-pix-fmt = "RGB666";  /* Try RGB666 instead of RGB24 */
    default_bpp = <18>;           /* Try 18-bit instead of 24-bit */
    status = "okay";
};

3. Alternative Panel Configuration

Based on the Iris carrier board implementation (2), you might need to adjust the panel configuration. The Iris board uses an LVDS transmitter that converts RGB signals to LVDS format.

Hardware Considerations

The Iris carrier board uses assembly options to select VGA output sources (2). Ensure that:

  • The correct resistors are assembled for RGB to VGA DAC signals (R14, R15, R16, R19, R20)
  • The LVDS transmitter on your carrier board is properly configured

Color Mapping Reference

According to the documentation (1), the 18-bit LVDS color mapping follows this pattern:

  • LVDS_TX0: Contains G0, R5, R4, R3, R2, R1, R0
  • LVDS_TX1: Contains B1, B0, G5, G4, G3, G2, G1
  • LVDS_TX2: Contains DE, VSYNC, HSYNC, B5, B4, B3, B2

Next Steps

  1. Test with 18-bit configuration first, as this is the most compatible format
  2. Verify your LVDS transmitter chip specifications to confirm the expected color mapping
  3. Check the physical connections between your Colibri module and the LVDS converter

Try the 18-bit configuration first, as compatibility issues between different color mapping standards can cause the red-tinted display you’re experiencing.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Hi, looks like red and blue are swapped. Did you try BGR format:

/* Interface LCD principale */
&lcd_display {
    interface-pix-fmt = "BGR24";
    default_bpp = <24>;
    status = "okay";
};

Hello @slou26,

I’m assuming that you used the right wiring from the SODIMM pins (pins for RGB Interface) to the LVDS transmitter (if not, please double check that). The splash screen for Torizon should normally have black background. This would indicate that one or more of the red data lines are constantly pulled high, which explains the red background. Since it is relatively bright, it is more likely to be one of the upper bits like from LCD_R5 to LCD_R7. Could you please measure the signals LCD_R0-LCD_R7 to figure out if one of them is stuck at one?

Another test you could do is displaying a black/red/blue/green image to see if it really displays that color:
black: dd if=/dev/zero of=/dev/fb0
green: printf "\xE0\x07" | dd of=/dev/fb0 bs=2 count=$((1024*600))

Also, as @s.steiger mentioned, looks like you are using the wrong option for interface-pix-fmt. You can try one of the following options:

interface-pix-fmt = "rgb24";
interface-pix-fmt = "rgb565";
interface-pix-fmt = "bgr666";
interface-pix-fmt = "lvds666";

Thanks @s.steiger … I have already try but no change always a red screen …
Strange that it doesn’t change the color, I even wonder if the overlay settings are applied correctly.
However, if I change the resolution, I can see the change, and I can see in the boot logs that the overlay is correctly applied.

When I execute the following command:

torizon@colibri-imx6-10907658:~$ fbset

mode “1024x600-0”

D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz

geometry 1024 600 1024 600 16
timings 0 0 0 0 0 0 0
accel false
rgba 5/11,6/5,5/0,0/0
endmode

why rgb565 ?

Hi @slou26,

I guess you need to change the interface-pix-fmt property of the mxcfb1 node. Adding

&mxcfb1 {
// default_bpp = <16>;
interface_pix_fmt = “BGR24”;
};

to your overlay should do the trick.

thanks @rudhi.tx .

I tryed to execute your command : “dd if=/dev/zero of=/dev/fb0” but:

dd: writing to ‘/dev/fb0’: No space left on device
2401+0 records in
2400+0 records out
1228800 bytes (1.2 MB, 1.2 MiB) copied, 0.0200477 s, 61.3 MB/s

and the screen is always red , with torizon logo …

Hi @s.steiger

I tryed to change the interface-pix-fmt , but I get stuck at boot :

(Jan 01 1970 - 00:00:00 +0000)
Commercial temperature grade DDR3 timings, 64bit bus width.
Trying to boot from MMC1

U-Boot 2024.07-7.3.0+git.3f772959501c (Jan 01 1970 - 00:00:00 +0000)

CPU: Freescale i.MX6DL rev1.4 996 MHz (running at 792 MHz)
CPU: Commercial temperature grade (0C to 95C) at 45C
Reset cause: POR
DRAM: 512 MiB
PMIC: device id: 0x10, revision id: 0x21, programmed
Core: 115 devices, 20 uclasses, devicetree: separate
WDT: Started watchdog@20bc000 with servicing every 1000ms (128s timeout)
MMC: FSL_SDHC: 1, FSL_SDHC: 0
Loading Environment from MMC… Reading from MMC(0)… OK
In: serial@2020000
Out: serial@2020000
Err: serial@2020000
Model: Toradex 0015 Colibri iMX6DL 512MB V1.1Y
Serial#: 10907658
Net: eth0: ethernet@2188000
Hit any key to stop autoboot: 0
Card did not respond to voltage select! : -110
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1…
Found U-Boot script /boot.scr
969 bytes read in 2 ms (472.7 KiB/s)

Executing script at 18280000

7050 bytes read in 2 ms (3.4 MiB/s)
65488 bytes read in 3 ms (20.8 MiB/s)
30 bytes read in 2 ms (14.6 KiB/s)
Working FDT set to 18200000
Applying Overlay: slo_overlay.dtbo
1774 bytes read in 3 ms (577.1 KiB/s)
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC
11129344 bytes read in 294 ms (36.1 MiB/s)
10590156 bytes read in 280 ms (36.1 MiB/s)
Kernel image @ 0x14200000 [ 0x000000 - 0xa9d200 ]
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
SCRIPT FAILED: continuing…
Card did not respond to voltage select! : -110
No EFI system partition
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
Loading Boot0000 ‘mmc 0’ failed
EFI boot manager: Cannot load any image
starting USB…
Bus usb@2184000: Bus usb@2184200: USB EHCI 1.00
scanning bus usb@2184000 for devices… 1 USB Device(s) found
scanning bus usb@2184200 for devices… 2 USB Device(s) found
scanning usb for storage devices… 0 Storage Device(s) found

Device 0: unknown device
BOOTP broadcast 1
DHCP client bound to address 10.1.60.94 (4 ms)
Using ethernet@2188000 device
TFTP from server 192.168.10.1; our IP address is 10.1.60.94; sending through gateway 10.1.60.90
Filename ‘boot.scr’.
Load address: 0x18280000
Loading: T T T T T T T T T T
Retry count exceeded; starting again
BOOTP broadcast 1
DHCP client bound to address 10.1.60.94 (3 ms)
Using ethernet@2188000 device
TFTP from server 192.168.10.1; our IP address is 10.1.60.94; sending through gateway 10.1.60.90
Filename ‘boot.scr’.
Load address: 0x14200000
Loading: *

Hi @slou26,

something is wrong with your overlay, bootloader fails to apply your overlay.

Working FDT set to 18200000
Applying Overlay: slo_overlay.dtbo
1774 bytes read in 3 ms (577.1 KiB/s)
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND

It looks like you are using a torizon build. I don’t know if the devicetree for torizon is different to a yocto build. My devicetree snippet should work for a BSP5 yocto build for an imx6dl colibri module. You need to check your devicetree for the correct reference.

For BSP5 the devicetree include is …/arch/arm/boot/dts/imx6qdl-colibri.dtsi, defining mxcfb1:

mxcfb1: fb@1 {
	compatible = "fsl,mxc_sdc_fb";
	disp_dev = "hdmi";
	interface_pix_fmt = "RGB24";
	mode_str ="640x480M@60";
	default_bpp = <16>;
	int_clk = <0>;
	late_init = <0>;
	status = "disabled";
};

There should be something similar in your devicetree.

And note, that the corresponding FB is fb1. So might want to try dd if=/dev/zero of=/dev/fb1 count=2400 and see if the screen turns black.

Hello @rudhi.tx ,

Could you try on your side to activate the last 6 LCD lines so that they are no longer stucked to 1 ?

(LCD 18 to 23 on the x7 connector of the colibri evaluation board V3.2b )

Torizon OS Upstream 7.3.0+build.18

Thanks for your help .

Hi @slou26,

Very sorry about the delay in getting back to you. I haven’t had the chance to experiment on my side. Will give it a try this week and will update you.

Hi @slou26,

You are right, the lines from LCD 18 to 23 (IPU1_DISP0_DATA18 to IPU1_DISP0_DATA23) were constantly being pulled to high. This is why you were seeing red color where it is supposed to be black. I fixed it by changing the pinctrl for lcd_display (pinctrl_ipu1_lcdif) to 24 lines → therefore 24 bit format. By default, the device tree for colibri-imx6dl is configured to use 18bpp format for the LCD display. Here is my working device tree overlay, on which I modified the above-mentioned pinctrl (and also removed &pinctrl_weim_gpio_1 and &pinctrl_weim_gpio_2 from pinctrl-0 for iomuxc, since it was using the LCD 18 to 23 line functions).

// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/*
 * Copyright 2020-2022 Toradex
 */

// Enable the parallel RGB interface on the Colibri iMX6.

#include <dt-bindings/pwm/pwm.h>

#include "imx6dl-pinfunc.h"

&lcd_display {
        /* use the bus-format as specified from the panel */
        interface-pix-fmt = "rgb24";
        status = "okay";
};

&panel_dpi {
        /*data-mapping = "bgr666";*/
        status = "okay";
};

&pwm1 {
        status = "okay";
};

&pwm2 {
        status = "disabled";
};

&pwm3 {
        status = "disabled";
};

&backlight {
        compatible = "pwm-backlight";
        brightness-levels = <0 45 63 88 119 158 203 255>;
        default-brightness-level = <4>;
        enable-gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* Colibri BL_ON */
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio_bl_on>;
        power-supply = <&reg_module_3v3>;
        pwms = <&pwm1 0 5000000 PWM_POLARITY_INVERTED>;
        status = "okay";
};

&iomuxc {
        pinctrl-names = "default";
        pinctrl-0 = <
                &pinctrl_weim_gpio_3 &pinctrl_weim_gpio_4
                &pinctrl_weim_gpio_5 &pinctrl_weim_gpio_6
                &pinctrl_usbh_oc_1 &pinctrl_usbc_id_1
        >;
};


/* Override existing LCD pinctrl group */
&pinctrl_ipu1_lcdif {
        fsl,pins = <
            MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK      0xa1
            MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15            0xa1
            MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02             0xa1
            MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03             0xa1
            MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00        0xa1
            MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01        0xa1
            MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02        0xa1
            MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03        0xa1
            MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04        0xa1
            MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05        0xa1
            MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06        0xa1
            MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07        0xa1
            MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08        0xa1
            MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09        0xa1
            MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10       0xa1
            MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11       0xa1
            MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12       0xa1
            MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13       0xa1
            MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14       0xa1
            MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15       0xa1
            MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16       0xa1
            MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17       0xa1
            MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18       0xa1
            MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19       0xa1
            MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20       0xa1
            MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21       0xa1
            MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22       0xa1
            MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23       0xa1
        >;
};

I tested this on colibri iMX6DL, Colibri evaluation board V3.2B, our standard 7" capacitive touch display. Of course, in this case, I see strange colors on the display since the display does not support 24bpp. I measured the LCD_D_17 to LCD_D_23 pins on the evaluation board and made sure they are not constantly pulled high. I believe with this pinctrl settings the display should work for you. Please give it a try and let me know how it goes.

One thing that seems abnormal :

cat /sys/class/graphics.fb0/bits_per_pixel
16

About this: I think it’s because the framebuffer driver it is using here is deprecated. You should read the right settings in DRM which will be accurate. So in your application, it’s best if you use DRM directly or weston which uses DRM.

Hello @rudhi.tx
Many thanks for your help !!
It’s working now …

@slou26,

Glad to hear that. Thanks for confirming.

hello @rudhi.tx, we have another issue with the screen
We have to rotate the screen to 180 ° ( hardware requirements)
I tryed to add this line : rotation = <180>;

&panel_dpi {
    compatible = "panel-dpi";
    status = "okay";
    width-mm = <330>;
    height-mm = <210>;
    data-mapping = "vesa-24";
    rotation = <180>;
 
    panel-timing {
        clock-frequency = <52000000>;
        hactive = <1024>;
        vactive = <600>;
        hsync-len = <64>;
        hfront-porch = <48>;
        hback-porch = <96>;
        vsync-len = <2>;
        vfront-porch = <10>;
        vback-porch = <33>;
        hsync-active = <1>;
        vsync-active = <0>;
        de-active = <0>;
        pixelclk-active = <0>;
    };
};

But only the splashscreen is rotated , all subsequent displays, such as the pairing code display, are not. How could I fixed it ? Thanks .

Hi @slou26,

I am not entirely sure why the easy pairing app is rotated/oriented wrongly for you. It is configured somewhere in its source code itself, which is a C # application. However, this should not matter much since you will have control over your final application.

If your application uses Weston as a window manager, this type of orientation configuration can be easily done by modifying the weston.ini file.
For a quick evaluation and prototyping, you can refer to this article to see how this is done: Working with Weston on Torizon OS | Toradex Developer Center

The weston.ini file that you need to change is in the Docker container itself - since this is the configuration file the application will look into. However, this weston.ini file is bind-mounted from the /etc/xdg/weston/ base Torizon OS, if it is present in the base OS. Therefore, you simply need to add such a file with the rotation configuration (as you saw in the link above) into /etc/xdg/weston/weston.ini file on the base OS, and it will eventually be copied into the Docker container, and those configurations will be applied in your weston-based application.

If you like to do a quick test, I suggest that you try one of our demo apps on the Torizon cloud (for example: qt5-wayland-examples-colibri-imx6), which is based on weston, and make the changes I proposed in the weston.ini file.

Thank you for your reply @rudhi.tx .
Perhaps I didn’t express myself clearly.
The simplified pairing application is correctly oriented; it’s simply the screen that’s mounted upside down on our machines (I don’t remember why, but it was for viewing comfort).
I’ll run some tests as you suggested. Thanks

Do you mean the splash screen is wrongly oriented then?

No, actually, without any changes to the overlay, the splash screen and the application display normally, but not for us because we physically install the screens upside down.

Therefore, it’s necessary to flip the display using software to get it right-side up.

If we change the overlay with a rotation of <180>, only the splash screen is flipped, not the application.