Diagonal Artifacts on MIPI-DSI Display When Running Weston on Torizon 6.8.x

Hi everyone,

We are currently adapting a new MIPI-DSI display on a Verdin i.MX8M Mini. For initial boot tests we used the tdx-reference-multimedia-image and the display worked as expected. However, with the same changes the display does not render correctly on Torizon OS 6.8.x.

When we build the Torizon image and run the Weston container, diagonal bands/stripes appear on the screen once Weston starts. These distortions do not appear during the splash screen — the splash screen is shown correctly (solid blue). I attach screenshots where we set the Weston background to a green color to make the bands more visible, and a short video that shows the splash screen followed by Weston and our application starting.

Attachments

  • Screenshot: weston_green_1.jpg
  • Screenshot: weston_green_2.jpg
  • Photo / video: splash_then_weston.mp4 (blue splash screen followed by Weston start)

Do you have any idea what might be causing the diagonal bands when Weston runs, or where we should start investigating?

Here is the DTS we are using to initialize the display.

#include <dt-bindings/gpio/gpio.h>
#include "dt-bindings/interrupt-controller/irq.h"

/ {
	compatible = "toradex,verdin-imx8mm";
};

&gpu {
	status = "okay";
};

&lcdif {
	status = "okay";
};

&backlight {
	status = "okay";
};

&mipi_dsi {
	#address-cells = <1>;
	#size-cells = <0>;
	status = "okay";

	panel@0 {
		#address-cells = <1>;
		#size-cells = <0>;
		compatible = "tdo,ET055wu01";
		reg = <0>;
		backlight = <&backlight>;
		dsi-lanes = <4>;
		video-mode = <0>;	/* 0: burst mode 1 (not supported): non-burst mode with sync event 2: non-burst mode with sync pulse */
		reset-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
		status = "okay";
	};
};

&i2c4 {
	#address-cells = <1>;
	#size-cells = <0>;
	
	touchscreen@5d {
		compatible = "goodix,gt911";
		reg = <0x5d>;
		/*
		 * Verdin GPIO_9_DSI
		 * (TOUCH_INT#, SODIMM 17, IRQ albeit currently unused)
		 */
		interrupt-parent = <&gpio3>;
		interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
		irq-gpios = <&gpio3 15 IRQ_TYPE_EDGE_FALLING>;
		/* Verdin I2S_2_BCLK (TOUCH_RESET#, SODIMM 21 ) */
		reset-gpios = <&gpio3 3 GPIO_ACTIVE_LOW>;
		status = "okay";
	};
};

I´m also sharing the timings and flags of this display

static const struct drm_display_mode ET055wu01_mode = {
.clock = 158400, // 158400

.hdisplay       = 1080,
.hsync_start    = 1080 + 20,      		// + HFP
.hsync_end      = 1080 + 20 + 6, 		// + Hsync width
.htotal         = 1080 + 20 + 6 + 204, 	// + HBP

.vdisplay       = 1920,
.vsync_start    = 1920 + 4,      		// + VFP
.vsync_end      = 1920 + 4 + 4,  		// + Vsync width
.vtotal         = 1920 + 4 + 4 + 79, 	// + VBP

.width_mm       = 62.2,
.height_mm      = 110.6,

.type  = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NHSYNC,

};

static const struct mipi_dsi_panel_panel_desc ET055wu01_desc= {
.mode = &ET055wu01_mode,
.lanes = 4,
.flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_HSE | MIPI_DSI_MODE_VIDEO_BURST |
MIPI_DSI_MODE_LPM,
.format = MIPI_DSI_FMT_RGB888,
.supply_names = infoblock_supply_names,
.num_supplies = ARRAY_SIZE(infoblock_supply_names),
.panel_sleep_delay = 200,
.init_sequence = ET055wu01_init_sequence,
};

This is my Dockerfile and the weston.ini that I used

[core]

idle-time=0

require-input=false

use-g2d=true

repaint-debug=1

[shell]

locking=false

num-workspaces=1

background-color=0xFF004400

#background-image=/etc/xdg/wallpaper.png

#background-type=centered

[output]

name=DSI-1

transform=rotate-90
# For arm64v8 use:

ARG IMAGE_ARCH=linux/arm64

#ARG BASE_NAME=weston

# For arm64v8 with Vivante use:

ARG BASE_NAME=weston-vivante

# Check out https://developer.toradex.com/torizon/working-with-torizon/provided-containers/torizoncore-containers-tags-and-versioning

ARG IMAGE_TAG=3

ARG DOCKER_REGISTRY=torizon

FROM --platform=$IMAGE_ARCH $DOCKER_REGISTRY/$BASE_NAME:$IMAGE_TAG AS base

COPY ./weston.ini /etc/xdg/weston/

COPY ./weston.ini /etc/xdg/weston-dev/

COPY ./wallpaper.png /etc/xdg/

Hi, I’m the Toradex AI Assistant.

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


MIPI-DSI Display Issues with Weston on Torizon OS

The diagonal bands/stripes you’re experiencing when Weston starts on Torizon OS 6.8.x, while the splash screen displays correctly, suggest a display timing or configuration mismatch between the kernel framebuffer and Weston’s display handling.

Key Differences Between Splash Screen and Weston

The splash screen uses the kernel’s framebuffer directly, while Weston uses the DRM (Direct Rendering Manager) subsystem (1). This explains why the splash screen appears correctly but Weston shows distortions.

Troubleshooting Steps

1. Verify Display Configuration

Check if your display is properly recognized by examining the DRM interface:

# ls /sys/class/drm/*/status

(1)

You should see your DSI display listed. For MIPI-DSI displays, you’ll typically see something like:

/sys/class/drm/card0-DSI-1/status

(1)

2. Weston Configuration Issues

Your weston.ini configuration shows:

[output]
name=DSI-1
transform=rotate-90

The name value should match what weston-info reports from inside the running Weston container (1). You can verify this by running:

docker exec <weston-container> weston-info

(1)

3. Display Timing Verification

The timing parameters in your display driver may not be correctly interpreted by Weston. Based on the community discussions, similar issues have been resolved by ensuring proper clock configuration (2) (3).

4. Container Configuration

For Verdin iMX8M Mini, ensure you’re using the correct Weston container. Your Dockerfile references weston-vivante, which is appropriate for iMX8 platforms (4):

# docker container run -d --name=weston --net=host \
    --cap-add CAP_SYS_TTY_CONFIG \
   -v /dev:/dev -v /tmp:/tmp -v /run/udev/:/run/udev/ \
    --device-cgroup-rule="c 4:* rmw" --device-cgroup-rule="c 253:* rmw" \
    --device-cgroup-rule="c 13:* rmw" --device-cgroup-rule="c 226:* rmw" \
    --device-cgroup-rule="c 10:223 rmw" --device-cgroup-rule="c 199:0 rmw" \
    torizon/weston-imx8:4 \
    --developer

(4)

Potential Solutions

1. Try Software Rendering

Test if the issue is related to hardware acceleration by using software rendering:

Add --use-pixman to your Weston startup command (1).

2. Check Display Mode Settings

Your display flags show:

.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NHSYNC

This appears to have a typo - you likely meant:

.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC

3. Verify Panel Driver Integration

Ensure your custom panel driver (tdo,ET055wu01) is properly loaded and recognized by the system. Check dmesg output for any panel-related errors.

Next Steps

  1. Verify the exact output name using weston-info
  2. Check dmesg logs for any DRM or display-related errors
  3. Test with --use-pixman to isolate hardware acceleration issues
  4. Ensure your device tree overlay is correctly applied in Torizon OS

The fact that your setup works with tdx-reference-multimedia-image but not with Torizon OS suggests there may be differences in the kernel configuration or display subsystem between the two environments.

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.

Based on the previous recommendations, here are the additional validations we performed:

Verification using weston-info

We executed the command again from inside the Weston container and confirmed that Weston correctly detects the panel under the output name DSI-1. Here is the relevant excerpt:

docker exec weston weston-info
*** Please use wayland-info instead
*** weston-info is deprecated and will be removed in a future version
interface: ‘zxdg_output_manager_v1’, version: 2, name: 4
xdg_output_v1
output: 20
name: ‘DSI-1’
logical_x: 0, logical_y: 0
logical_width: 1920, logical_height: 1080
interface: ‘wp_presentation’, version: 1, name: 5
presentation clock id: 1 (CLOCK_MONOTONIC)
name: default
capabilities: keyboard touch
keyboard repeat rate: 40
keyboard repeat delay: 400
interface: ‘wl_output’, version: 3, name: 20
x: 0, y: 0, scale: 1,
physical_width: 62 mm, physical_height: 110 mm,
make: ‘unknown’, model: ‘unknown’,
subpixel_orientation: unknown, output_transform: 90°,
mode:
width: 1080 px, height: 1920 px, refresh: 60.475 Hz,
flags: current preferred
interface: ‘weston_desktop_shell’, version: 1, name: 25
interface: ‘weston_screenshooter’, version: 1, name: 26rface: ‘wl_subcompositor’, version: 1, name: 2
interface: ‘wp_viewporter’, version: 1, name: 3
interface: ‘zxdg_output_manager_v1’, version: 2, name: 4
xdg_output_v1
output: 20
name: ‘DSI-1’
logical_x: 0, logical_y: 0
logical_width: 1920, logical_height: 1080
x: 0, y: 0, scale: 1,
physical_width: 62 mm, physical_height: 110 mm,
make: ‘unknown’, model: ‘unknown’,
subpixel_orientation: unknown, output_transform: 90°,
mode:
width: 1080 px, height: 1920 px, refresh: 60.475 Hz,
flags: current preferred

This confirms that Weston is indeed using DSI-1 as the output for the panel.

DRM status under /sys/class/drm

Running:

ls /sys/class/drm/*/status

shows:

/sys/class/drm/card1-DSI-1/status

This indicates that the panel is exposed under card1, not card0.
The node exists and reports connected, so the MIPI-DSI bridge and the panel driver are being registered properly.

Directory structure:

torizon@verdin-imx8mm-15543033:~$ ls /sys/class/drm/*/status
/sys/class/drm/card1-DSI-1/status
torizon@verdin-imx8mm-15543033:~$ ls /sys/class/drm/*       
/sys/class/drm/version

/sys/class/drm/card0:
dev  device  power  subsystem  uevent

/sys/class/drm/card1:
card1-DSI-1  dev  device  power  subsystem  uevent

/sys/class/drm/card1-DSI-1:
device  dpms  edid  enabled  modes  power  status  subsystem  uevent

/sys/class/drm/renderD128:
dev  device  power  subsystem  ueven

Testing Weston with --use-pixman

We also tested starting Weston using software rendering with --use-pixman, but the result is exactly the same, so the distortion does not appear to be related to GPU acceleration.

Behavior on tdx-reference-multimedia-image

In contrast, with tdx-reference-multimedia-image the display boots correctly, with no diagonal lines or artifacts. This confirms that:

  • The panel works
  • The panel timings are correct
  • The device tree is valid

The following image is from the tdx-reference-multimedia-image, where the display works without any issues.

The fact that your display works correctly on tdx-reference-multimedia-image but shows diagonal bands on Torizon OS 6.8.x, despite using the same device tree configuration, points to differences in the underlying kernel or display subsystem between these environments.

Key Observations

Your verification confirms several important points:

  • Weston correctly detects the panel as DSI-1 (1)
  • The display is connected on card1 (not card0)
  • Software rendering (--use-pixman) produces the same artifacts, ruling out GPU acceleration issues (1)
  • The panel hardware and timings are correct (proven by working tdx-reference-multimedia-image)

Potential Root Causes

1. Multi-Display DRM Interface Issue

The fact that your display appears on card1 instead of card0 suggests a multi-DRM interface scenario. According to the documentation, “Weston container extends its surface to all displays connected to the same DRM interface and display controller. Currently, Weston is unable to manage outputs, connected to multiple DRM interfaces” (1).

Since your display is on card1-DSI-1, you may need to launch Weston specifically for that DRM interface.

2. Seat Configuration for Multiple DRM Cards

For modules with multiple DRM interfaces, you need to associate each output with a seat name by setting the ID_SEAT property (1). Try creating a udev rule:

# cat /etc/udev/rules.d/72-seat-drm-platform-display-subsystem.rules
TAG=="seat", ENV{ID_FOR_SEAT}=="drm-platform-display-subsystem", ENV{ID_SEAT}="seat1"

(1)

After creating this rule, reboot and launch Weston on the specific seat:

docker run -e ACCEPT_FSL_EULA=1 -d --rm --name=weston --net=host --cap-add CAP_SYS_TTY_CONFIG \
             -v /dev:/dev -v /tmp:/tmp -v /run/udev/:/run/udev/ \
             --device-cgroup-rule='c 4:* rmw' --device-cgroup-rule='c 13:* rmw' \
             --device-cgroup-rule='c 199:* rmw' --device-cgroup-rule='c 226:* rmw' \
             torizon/weston-vivante:$CT_TAG_WESTON_VIVANTE --developer \
            --tty=/dev/tty7  -- --seat=seat1

(1)

3. Force Connector State

Since your display is working in the splash screen but not in Weston, try forcing the connector state (1):

echo on > /sys/class/drm/card1-DSI-1/status

(1)

4. Fixed Display Resolution Configuration

Weston supports setting the resolution in the configuration file (1). Try adding explicit mode settings to your weston.ini:

[output]
name=DSI-1
mode=1080x1920@60
transform=rotate-90

(1)

Recommended Troubleshooting Steps

  1. Check for multiple display controllers: Verify if card0 has any associated displays that might be interfering
  2. Test without rotation: Temporarily remove transform=rotate-90 from your weston.ini to isolate rotation-related issues
  3. Check kernel version differences: Compare the kernel versions between tdx-reference-multimedia-image and your Torizon OS 6.8.x build
  4. Examine DRM debugging: Enable DRM debugging to get more detailed information about the display initialization

The diagonal banding pattern typically indicates timing or synchronization issues between the display controller and the panel, which could be caused by the multi-DRM interface handling differences between the two environments.

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.

Hello @Isaga !

Since the issue reproduces even with --use-pixman, and Weston is detecting the mode properly, it suggests that the distortion might be happening before Weston’s rendering stage, somewhere in the DRM/MIPI-DSI pipeline on TorizonOS.

I know you provided some logs already, but could you please collect two additional diagnostics from both images? This might help us get a clearer picture of might be happening.

  • DRM mode information from the kernel
    modetest -M imx-drm

  • Kernel logs related to LCDIF, DSI, and the panel driver
    dmesg | grep -Ei "mipi|dsi|lcdif|panel"

These will let us see if Torizon OS is selecting a different pixel format, buffer modifier, or DRM mode compared to the multimedia image.

Hello @joaom.tx!

Thanks for the response. We also suspect an issue related to the DRM/MIPI-DSI pipeline. I will update the post with the requested logs.

While running additional tests, we updated Torizon OS to version 7.4.0, and in this case, the artifacts did not appear in the final image.

Regards!

@Isaga ,

Perfect! Good to hear that it is working as it should on a newer TorizonOS version! Let us know if you run into any similar issues again and if you get to those logs, it would be helpful for us to diagnose any possible problems!