Has anyone had similar problems with mxsfb-drm driver on Colibri iMX8X with BSP 7.4. It has a fundamental coordinate transformation bug where rotation and reflection operations are swapped, and attempting to correct it causes further axis swapping.
The Real Problem
This is a driver-level bug in the mxsfb-drm kernel driver specific to the Colibri iMX8X parallel RGB interface. Since:
- Plymouth and console display correctly (direct KMS)
- X.Org with modesetting introduces the issue
- XRandR operations are swapped/broken
- All 16 transformation combinations fail
- Attempting corrections causes additional axis swapping
The modesetting DDX driver cannot properly communicate transformations to the mxsfb-drm kernel driver.
Hi, I’m the Toradex AI Assistant.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
I’d be glad to help! Could you let me know which OS and version you are using? You can run the tdx-info command to get detailed information about your system configuration. You can learn more about this command at tdx-info documentation.
Colibri iMX8X Display Architecture
The Colibri iMX8X uses the mxsfb-drm driver for the parallel RGB interface (1). According to the documentation, the parallel RGB interface is managed through the mxsfb-drm DRM driver (1).
For BSP 7.x, the Colibri iMX8X display configuration shows:
| Description |
Parallel RGB |
| Device-Tree Node Reference |
panel_dpi |
| DRM Driver |
mxsfb-drm |
| DRM Card |
card1 |
| DRM Connector Name |
DPI-1 |
(1)
Known Display Issues
The documentation mentions that newer kernels require proper bridge and display chain node definitions, and that bridges must be declared properly in the device tree (2). For mxsfb driver issues, the error typically indicates problems with device tree configuration where the display controller cannot find or attach a display bridge (2).
Once you provide your OS version information, I can give you more specific guidance for your BSP 7.4 setup and help troubleshoot the coordinate transformation issues you’re experiencing with the mxsfb-drm driver.
Best regards, Toradex AI Assistant.
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
tdx-info
Software summary
Bootloader: U-Boot
Kernel version: 6.6.101-7.4.0-devel #1 SMP PREEMPT Thu Sep 25 07:49:28 UTC 2025
Kernel command line: root=PARTUUID=2fa5ad46-02 ro rootwait console=tty1 console=ttyLP3,115200 bootdelay=0 quiet splash plymouth.ignore-serial-consoles vt.global_cursor_default=0 console=ttymxc0,115200n8
Distro name: NAME=“TDX Wayland with XWayland”
Distro version: VERSION_ID=7.4.0-devel-20251219092505-build.0
Distro variant: -
Hostname: colibri-imx8x-07014439
Hardware info
HW model: Toradex Colibri iMX8QXP on Colibri Evaluation Board V3
Toradex version: 0050 V1.0D
Serial number: 07014439
Processor arch: aarch64
Thank you for providing the system information! You’re running BSP 7.4.0-devel with kernel 6.6.101 on a Colibri iMX8QXP V1.0D with the TDX Wayland with XWayland distribution.
Display Configuration for Colibri iMX8X
Your setup uses the mxsfb-drm driver for the parallel RGB interface (1). The Colibri iMX8X display configuration shows:
| Description |
Parallel RGB |
| Device-Tree Node Reference |
panel_dpi |
| DRM Driver |
mxsfb-drm |
| DRM Card |
card1 |
| DRM Connector Name |
DPI-1 |
(1)
Known DRM Driver Issues
The coordinate transformation issues you’re experiencing with the mxsfb-drm driver appear to be related to kernel-level DRM implementation problems. Similar issues have been documented with i.MX DRM drivers where the driver implementation has limitations (2).
Potential Solutions
1. Device Tree Configuration
Ensure your device tree overlay properly configures the display chain. For newer kernels, bridges must be declared and properly connected (3). The device tree should include proper port and endpoint nodes to connect the controller to any bridge components (3).
2. Kernel Configuration Check
Since you’re on a development build (7.4.0-devel), consider checking if this is a known issue in the specific kernel version. The documentation indicates that some configurations and drivers may adversely affect performance and functionality (4).
3. Alternative Approaches
- Wayland/Weston Compositor: Since you’re using TDX Wayland with XWayland, the Wayland compositor may handle transformations differently than X.Org
- Direct DRM/KMS: Consider bypassing X.Org transformations and handling rotation at the application level using direct DRM/KMS calls
Building Custom Kernel
If needed, you can build a custom kernel with patches to address the mxsfb-drm driver issues. The build process is documented for BSP 7.x (5), though note that building from source may affect graphical functionality compared to the official BSP (5).
The coordinate transformation bug you’ve identified in the mxsfb-drm driver appears to be a kernel-level issue that may require driver-level fixes or workarounds at the compositor level.
Best regards, Toradex AI Assistant.
**
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Hello @medicalSpark !
Based on the symptoms you have said, I wouldn’t assue that XRandR is broken as the root cause just yet. On i.MX8X you have two DRM devices in play, and “rotation/reflect swapped” is exactly the kind of thing you can see when userspace talks to the wrong KMS device/plane, or when the DRM rotation property is exposed but implemented/mapped incorrectly for that driver.
Parallel RGB uses mxsfb-drm, usually as /dev/dri/card1 with connector DPI-1. HDMI/LVDS are typically on imx-drm (/dev/dri/card0).
If Xorg binds to /dev/dri/card0 but your visible panel is on card1 (mxsfb-drm), rotations can look weird because you’re rotating a different scanout or doing composition in a different stage than expected.
- Confirm what’s actually running:
ps -ef | egrep 'weston|Xorg|Xwayland'
- Check which DRM node Xorg bound to:
cat /var/log/Xorg.0.log | egrep -i 'drm|kms|modeset|card[0-9]|DPI-1|HDMI'
You’re looking for lines like modeset(0): using /dev/dri/cardX and the connector name it picked.
- Enumerate DRM devices and connectors:
ls -l /dev/dri/by-path/modetest -c -D /dev/dri/card0modetest -c -D /dev/dri/card1
If X is binding to card0 while your panel is exposed as DPI-1 on card1, you must ensure that Xorg is using the DRM device that owns the DPI-1 connector. Otherwise, rendering and KMS operations (such as rotation, reflection, and page-flipping) will be routed through a different DRM device and hardware-accelerated display features will not behave correctly.
