Changing rgb666 to bdr666 in device tree overlay

Technical Support
, , , ,
1

Hi, we have a custom board that wires displaypins different from evaluation board to LVDS interface on colibri imx7d.

I have tried in device-tree overlay:

&panel_dpi {            
status = "okay";               
compatible = "netron-dy,e231732"; 
data-mapping = "bgr666"; 
};

and

&panel_dpi {               
status = "okay";               
compatible = "netron-dy,e231732";
data-mapping = "rgb666"; 
};

but the resulting colors are the same (b and r swapped - as our hardware)

Any suggestions would be appreciated.

BR - Paul

2

Hi, I’m the Toradex AI Assistant.

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

To help you properly with the color mapping issue on your Colibri iMX7D, I need to clarify a few details about your setup:

  1. Which OS and version are you running? (e.g., BSP 6.x, BSP 7.x, Torizon OS)
  2. Are you using Yocto-based BSP or Torizon OS?

You can get this information by running the tdx-info command on your device. For more details, see: Getting Device Information with Tdx-Info | Toradex Developer Center

Initial Observations

The data-mapping property you’re trying to use is typically associated with LVDS panels when using the panel-lvds driver. However, for parallel RGB/DPI interfaces on the Colibri iMX7D, the configuration approach may be different.

According to the documentation, for the Colibri iMX7, display configurations including parallel RGB are supported(1). The panel_dpi node is indeed used for parallel RGB displays(2).

Potential Issues

  1. Driver compatibility: The data-mapping property may not be recognized by the driver you’re using if it’s expecting fsl,interface-pix-fmt instead
  2. Property not being applied: Your overlay may not be overriding the base device tree property correctly

Once you provide the OS version information, I can give you more specific guidance on:

  • The correct property syntax for your BSP version
  • Whether you need to modify the pin multiplexing in addition to the color mapping
  • How to verify that your overlay is being applied correctly

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.

3

@ToradexAI

Colibri imx7D 1G , BSP 7.8.0 , kernel 6.12.100

Toradex Yocto build guide : tdx-reference-minimal-image

4

Thank you for providing those details. Now I can give you specific guidance for your Colibri iMX7D setup.

Understanding the Issue

For the Colibri iMX7D parallel RGB interface, the data-mapping property you’re using is not the correct approach. The parallel RGB interface on iMX7 uses a different configuration method than LVDS panels.

Solution: Use interface-pix-fmt

Based on the Toradex documentation for display configuration, you need to modify the pixel format property in your device tree overlay. However, the standard property for parallel RGB on iMX7 is typically interface-pix-fmt or configured at the display controller level, not through data-mapping.

Recommended Approach

For your custom wiring with swapped R and B channels, you have a few options:

Option 1: Check if Your Panel Driver Supports Color Swap

Some panel drivers support properties to handle color channel swapping. You might need to add or modify:

&panel_dpi {
    status = "okay";
    compatible = "netron-dy,e231732";
    /* Try adding these properties */
    red-offset = <16>;
    green-offset = <8>;
    blue-offset = <0>;
};

Option 2: Modify at the LCD Controller Level

The color format is often controlled at the LCD controller (lcdif) node level. You may need to modify the interface-pix-fmt property there instead of in the panel node.

Option 3: Hardware-Specific Pin Mapping

Since you mentioned your hardware wires the display pins differently, you might need to:

  1. Verify your overlay is actually being applied (check dmesg output)
  2. Consider that the pin mapping might need to be adjusted at the pinctrl level, not just the panel level

Next Steps

  1. Verify your overlay is loading: Check the boot log with dmesg | grep overlay to confirm your device tree overlay is being applied(1)

  2. Check the base device tree: Look at the base device tree for Colibri iMX7 to see what properties are actually being used for the parallel RGB interface

  3. Consider kernel driver limitations: The data-mapping property is primarily for LVDS panels using the panel-lvds driver. For parallel RGB/DPI, different properties apply

Could you share:

  • The complete device tree overlay you’re using?
  • Any relevant dmesg output related to the display initialization?

This will help identify whether the overlay is being applied and what the actual driver expects.

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.

5

@ToradexAI

setting red green blue offset does not change it, fbset also shows the same color offset independant of the setting in device-tree.

Do i need to make pinctrl remapping of all MX7D_PAD_LCD_DATA##__LCD_DATA## ?

6

Based on the available documentation, I need to clarify that remapping individual LCD_DATA pins via pinctrl is not the correct approach for solving color channel swapping on the Colibri iMX7D.

Understanding the Architecture

The parallel RGB interface on iMX7D uses dedicated LCD data pins (LCD_DATA00 through LCD_DATA23) that are already configured for their LCD function. These pins carry the RGB data in a specific bit order that’s determined by the display controller (LCDIF), not by individual pin remapping(1).

Why Pinctrl Remapping Won’t Work

The MX7D_PAD_LCD_DATA## pins are dedicated display interface pins. They don’t have alternate GPIO or other functions that would allow you to “swap” them. The pinctrl subsystem controls pin function selection (muxing), pull-ups/downs, and drive strength—not the logical mapping of color channels(1).

Actual Solutions for Color Channel Swapping

Since the data-mapping property and offset settings aren’t working, and pinctrl remapping isn’t applicable, you have these options:

Option 1: Hardware Fix (Recommended)

If your custom carrier board has R and B channels physically swapped compared to the standard pinout, the proper solution is to correct the hardware wiring to match the standard Colibri iMX7D parallel RGB pinout.

Option 2: Software Workaround at Application Level

Since the kernel-level color format configuration isn’t providing the swap you need, you may need to handle this at the application/framebuffer level by implementing color conversion in your graphics stack or application code.

Option 3: Custom Kernel Driver Modification

You could potentially modify the LCDIF driver to swap the R and B channels, but this would require:

  • Custom kernel modifications
  • Maintaining those modifications across BSP updates
  • This is not recommended for production

Verification Steps

Before proceeding further, please verify:

  1. Check if your overlay is actually being applied:
cat /proc/device-tree/chosen/overlays/your-overlay-name.dtbo

If it returns 0, the overlay was applied successfully(2).

  1. Examine the actual panel driver being used:
dmesg | grep -i panel
dmesg | grep -i lcdif
  1. Confirm your hardware wiring - verify which physical pins on your custom board connect to which LCD_DATA lines on the Colibri module.

Recommendation

Given that you have custom hardware with non-standard wiring, the most reliable solution is to correct the hardware design to match the standard Colibri iMX7D RGB interface pinout. Software workarounds for hardware wiring issues are fragile and difficult to maintain.

If hardware changes aren’t possible, please share:

  • Your complete device tree overlay file
  • The output of dmesg | grep -E "panel|lcdif|display"
  • Details about which specific LCD_DATA pins are swapped on your hardware

This will help determine if there’s any driver-level configuration we’re missing.

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.

7

@ToradexAI

root@colibri-imx7-emmc-08731298:~# dmesg | grep panel
[    0.082680] /soc/bus@30400000/lcdif@30730000: Fixed dependency cycle(s) with /panel-dpi
[    0.082829] /panel-dpi: Fixed dependency cycle(s) with /soc/bus@30400000/lcdif@30730000
[    6.555273] panel-simple panel-dpi: Specify missing connector_type
root@colibri-imx7-emmc-08731298:~# dmesg | grep lcdif
[    0.082680] /soc/bus@30400000/lcdif@30730000: Fixed dependency cycle(s) with /panel-dpi
[    0.082829] /panel-dpi: Fixed dependency cycle(s) with /soc/bus@30400000/lcdif@30730000
[    6.600022] [drm] Initialized mxsfb-drm 1.0.0 for 30730000.lcdif on minor 0
[    6.838338] mxsfb 30730000.lcdif: [drm] fb0: mxsfb-drmdrmfb frame buffer device
8

Thank you for providing the dmesg output. Based on this information, I can see that:

  1. Your panel is using the panel-simple driver (panel-simple panel-dpi)
  2. The display controller is mxsfb-drm (the LCDIF driver for iMX7)
  3. The system is successfully initializing the framebuffer

The Core Issue

The panel-simple driver and the mxsfb-drm driver on iMX7 do not support runtime color channel swapping through device tree properties like data-mapping or color offsets. These properties work for LVDS panels using the panel-lvds driver, but not for parallel RGB with panel-simple[(1)](https://developer.toradex.com/linux-bsp/application-development/multimedia/display-output-resolution-and-timings-linux).

Understanding the Limitation

For Colibri iMX7D parallel RGB interface:

Available Solutions

Option 1: Hardware Correction (Strongly Recommended)

Since your custom carrier board has the R and B channels physically swapped, the proper engineering solution is to correct the PCB design to match the standard Colibri iMX7D parallel RGB pinout. This is the only reliable, maintainable solution.

Option 2: Kernel Driver Modification

You would need to modify the mxsfb driver source code to swap the R and B channels at the register level. This requires:

  • Forking and maintaining a custom kernel
  • Modifying the LCDIF controller register configuration
  • Maintaining these changes across BSP updates
  • This approach is not recommended for production

Option 3: Application-Level Color Conversion

Implement color channel swapping in your application or graphics framework before writing to the framebuffer. This is a software workaround that:

  • Adds processing overhead
  • Requires modification of all graphics applications
  • Is fragile and difficult to maintain

Why Pinctrl Remapping Will NOT Work

To directly answer your question: No, you cannot remap LCD_DATA pins via pinctrl to swap color channels.

The MX7D_PAD_LCD_DATA## pins are dedicated display interface pins. The pinctrl system controls:

  • Pin function selection (muxing between different peripheral functions)
  • Electrical properties (pull-up/down, drive strength)

It does not control the logical bit assignment within the display controller. The LCDIF hardware controller has a fixed mapping of which bit positions correspond to which LCD_DATA output pins[(2)](https://developer.toradex.com/linux-bsp/os-development/build-yocto/device-tree-overlays-linux).

Final Recommendation

Given the architectural limitations of the iMX7 LCDIF controller and the Linux display drivers:

  1. Correct the hardware design - This is the only proper solution
  2. If hardware changes are absolutely impossible, you'll need to implement color swapping in your application layer or fork the kernel driver

The device tree and overlay system cannot solve a hardware wiring mismatch for parallel RGB on the Colibri iMX7D.

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.

9

Hello @pfarre,

As the Colibri iMX7 has no LVDS interface, I assume you meant the Parallel RGB (DPI) interface.

The color mapping of this interface is fixed, depending only on the number of bits used for the interface, please see below table from datasheet:

Screenshot_20260810_152632
Screenshot_20260810_1526321573×1645 366 KB

Changing this is not possible, therefore the solution would be to rewire the signals in hardware, either on the carrier board, display cable, or via a simple adapter.

Possible software workarounds would involve rendering “incorrectly” to the framebuffer, with the red and blue channels swapped.
This could be possible, but may involve quite some work.

Best Regards,
Bruno