I’m trying to get anything to show up on my display but for some reason my Weston container doesn’t want to corporate.
The screen is on and the backlight is “4”.
I am using verdin-imx8mp_panel-cap-touch-10inch-dsi_overlay.dtbo for the overlay.
When I run this command: “find /sys/devices -name “edid”” I get back /sys/devices/platform/display-subsystem/drm/card0/card0-LVDS-1/edid which says LVDS. Is this correct?
Can someone give me some steps to get this to work please
Hi, I’m the Toradex AI Assistant.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer? 
Hello! I’d be happy to help you set up your display.
Based on your output, your system is currently detecting an LVDS display (as indicated by /sys/devices/platform/display-subsystem/drm/card0/card0-LVDS-1/edid). However, you mentioned you are using the DSI overlay (verdin-imx8mp_panel-cap-touch-10inch-dsi_overlay.dtbo). There appears to be a mismatch between your overlay configuration and what the system detects, and this is likely why Weston isn’t starting properly.
Here’s how you can proceed:
Verify the Actual Display Interface
Select the Correct Device Tree Overlay
verdin-imx8mp_panel-cap-touch-10inch-dsi_overlay.dtboverdin-imx8mp_panel-cap-touch-10inch-lvds_overlay.dtbo (see more here)Apply the Overlay and Reboot
Start the Weston Container
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" \
torizon/arm64v8-debian-weston
Check for Errors
docker logs weston
If Still Not Working
docker logs weston)tdx-info -dt
Following these steps will help resolve the mismatch and should get Weston displaying on your screen. If you continue to face issues, please provide the logs and display details for further troubleshooting.
Best regards,
Toradex AI Assistant.
I am using DSI for the display. So I don’t know why LVDS is showing up with hhat command. I am using the correct dtbo.
When I try running the container arm64v8 debian weston wasn’t working so I used torizon/weston-vivante:3.
Here is tdx-info -dt:
Compatible string: toradex,verdin-imx8mp-wifi-devtoradex,verdin-imx8mp-wifitoradex,verdin-imx8mpfsl,imx8mp
Device trees available:
imx8mp-verdin-nonwifi-dahlia.dtb
imx8mp-verdin-nonwifi-dev.dtb
imx8mp-verdin-nonwifi-ivy.dtb
imx8mp-verdin-nonwifi-mallow.dtb
imx8mp-verdin-nonwifi-yavia.dtb
imx8mp-verdin-wifi-dahlia.dtb
imx8mp-verdin-wifi-dev.dtb
imx8mp-verdin-wifi-ivy.dtb
imx8mp-verdin-wifi-mallow.dtb
imx8mp-verdin-wifi-yavia.dtb
Overlays available:
verdin-imx8mp_dsi-to-hdmi_overlay.dtbo
verdin-imx8mp_dsi-to-lvds_panel-cap-touch-10inch-lvds_overlay.dtbo
verdin-imx8mp_dsi-to-lvds_panel-lvds-dual-channel-1080p_overlay.dtbo
verdin-imx8mp_hdmi_overlay.dtbo
verdin-imx8mp_hmp_overlay.dtbo
verdin-imx8mp_mezzanine_ov5640-alt-jumpers_overlay.dtbo
verdin-imx8mp_mezzanine_ov5640-default-jumpers_overlay.dtbo
verdin-imx8mp_mezzanine_panel-cap-touch-10inch-lvds_overlay.dtbo
verdin-imx8mp_mezzanine_panel-lvds-dual-channel-1080p_overlay.dtbo
verdin-imx8mp_nau8822-btl_overlay.dtbo
verdin-imx8mp_ov5640_overlay.dtbo
verdin-imx8mp_panel-cap-touch-10inch-dsi_overlay.dtbo
verdin-imx8mp_panel-cap-touch-10inch-lvds_overlay.dtbo
verdin-imx8mp_panel-cap-touch-7inch-dsi_overlay.dtbo
verdin-imx8mp_spidev_overlay.dtbo
Hi @Shadiez
Welcome to the community. When asking questions in the community, please provide a detailed description of your issue.
Can you provide some basic information about your device?
docker ps -a?The biggest issue I think i am finding is that it is trying to use LVDS but I have a DSI board.
Here is the Tdx-Info Output:
For command to get weston up:
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
and then
docker run -e ACCEPT_FSL_EULA=1 -d --rm --name=wayland-app \ -v /dev/dri:/dev/dri -v /dev/galcore:/dev/galcore -v /tmp:/tmp \ --device-cgroup-rule='c 199:* rmw' --device-cgroup-rule='c 226:* rmw' \ torizon/weston-imx8:4 weston-terminal
I was following this for those commands: Setting up Displays with Torizon | Toradex Developer Center
Here is the output of docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c1222d889757 torizon/weston-imx8:4 “/usr/bin/entry.sh -…” 45 seconds ag o Up 44 seconds weston
d31ad22e34d5 torizon/chromium “/usr/bin/start-brow…” 4 hours ago Exited (1) 4 hours ago torizon-chromium-1
d20eca9cec14 torizon/weston-vivante “/usr/bin/entry.sh -…” 4 hours ago Exited (1) 4 hours ago torizon-weston-1
77aab5950095 torizon/weston:stable-rc “/usr/bin/entry.sh” 38 hours ago Exited (1) 38 hours ago pedantic_booth
96500a1bff16 torizon/weston:stable-rc “/usr/bin/entry.sh” 38 hours ago Exited (1) 38 hours ago interesting_kowalevski
torizon@verdin-imx8mp-15337091:~$
And finally here are docker logs: docker logs -f weston
Switching VT tty1 to text mode if currently in graphics mode
Switching to VT 7
SoC is: ‘i.MX8MP’
SoC has GPU: true
SoC has DPU: false
g2d implementation: viv
Removing previously created ‘.X*-lock’ entries under /tmp before starting Weston. Pass ‘IGNORE_X_LOCKS=1’ environment variable to Weston container to disable this behavior.
dos2unix: converting file /etc/xdg/weston/weston.ini to Unix format…
dos2unix: converting file /etc/xdg/weston-dev/weston.ini to Unix format…
00:00:00.000 [INFO] [seatd/seat.c:39] Created VT-bound seat seat0
00:00:00.000 [INFO] [seatd/seatd.c:194] seatd started
Date: 2025-05-28 UTC
[23:46:12.138] weston 12.0.4
wayland
Bug reports to:
Build: 12.0.4
[23:46:12.139] Command line: weston -Bdrm-backend.so -Swayland-0 --use-g2d
[23:46:12.139] OS: Linux, 6.6.84-7.2.0-g87bfb710b6f1, #1-Torizon SMP PREEMPT Mon Mar 31 08:47:48 UTC 2025, aarch64
[23:46:12.139] Flight recorder: enabled
[23:46:12.140] Using config file ‘/etc/xdg/weston-dev/weston.ini’
[23:46:12.141] Output repaint window is 7 ms maximum.
[23:46:12.143] Loading module ‘/usr/lib/aarch64-linux-gnu/libweston-12/drm-backend.so’
[23:46:12.176] initializing drm backend
[23:46:12.176] Trying libseat launcher…
00:00:00.094 [INFO] [seatd/server.c:145] New client connected (pid: 29, uid: 1000, gid: 1000)
00:00:00.094 [INFO] [seatd/seat.c:170] Added client 7 to seat0
00:00:00.095 [INFO] [seatd/seat.c:480] Opened client 7 on seat0
[23:46:12.177] [libseat/libseat.c:73] Seat opened with backend ‘seatd’
[23:46:12.177] [libseat/backend/seatd.c:212] Enabling seat
[23:46:12.177] libseat: session control granted
[23:46:12.181] using /dev/dri/card0
[23:46:12.181] DRM: supports atomic modesetting
[23:46:12.181] DRM: does not support GBM modifiers
[23:46:12.181] DRM: does not support async page flipping
[23:46:12.181] DRM: supports picture aspect ratio
[23:46:12.182] Loading module ‘/usr/lib/aarch64-linux-gnu/libweston-12/g2d-renderer.so’
[23:46:12.561] event1 - gpio-keys: is tagged by udev as: Keyboard
[23:46:12.561] event1 - gpio-keys: device is a keyboard
[23:46:12.564] event0 - 30370000.snvs:snvs-powerkey: is tagged by udev as: Keyboard
[23:46:12.564] event0 - 30370000.snvs:snvs-powerkey: device is a keyboard
[23:46:12.568] event2 - ilitek_ts: is tagged by udev as: Touchscreen
[23:46:12.568] event2 - ilitek_ts: device is a touch device
[23:46:12.640] event3 - MOSART Semi. 2.4G Wireless Mouse: is tagged by udev as: Mouse
[23:46:12.640] event3 - MOSART Semi. 2.4G Wireless Mouse: device is a pointer
[23:46:12.646] event4 - MOSART Semi. 2.4G Wireless Mouse: not tagged as supported input device
[23:46:12.756] event4 - not using input device ‘/dev/input/event4’
[23:46:12.801] libinput: configuring device “gpio-keys”.
[23:46:12.802] libinput: configuring device “30370000.snvs:snvs-powerkey”.
[23:46:12.802] Touchscreen - ilitek_ts - /sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-0041/input/input2/event2
[23:46:12.802] libinput: configuring device “ilitek_ts”.
[23:46:12.802] input device event2 has no enabled output associated (none named), skipping calibration for now.
[23:46:12.802] libinput: configuring device “MOSART Semi. 2.4G Wireless Mouse”.
[23:46:12.802] DRM: head ‘LVDS-1’ found, connector 35 is connected, EDID make ‘unknown’, model ‘unknown’, serial ‘unknown’
Supported EOTF modes: SDR
[23:46:12.803] Registered plugin API ‘weston_drm_output_api_v1’ of size 40
[23:46:12.803] Registered plugin API ‘weston_drm_virtual_output_api_v2’ of size 48
[23:46:12.803] Color manager: no-op
[23:46:12.803] Module ‘/usr/lib/aarch64-linux-gnu/libgbm.so’ already loaded
[23:46:12.804] Output ‘LVDS-1’ attempts EOTF mode: SDR
[23:46:12.804] Output ‘LVDS-1’ using color profile: built-in default sRGB SDR profile
[23:46:12.810] Initialized backlight for head ‘LVDS-1’, device /sys/class/backlight/backlight-verdin-dsi
[23:46:12.811] Output LVDS-1 (crtc 33) video modes:
1280x800@60.3, preferred, current, 71.1 MHz
[23:46:12.811] associating input device event1 with output LVDS-1 (none by udev)
[23:46:12.811] associating input device event0 with output LVDS-1 (none by udev)
[23:46:12.811] associating input device event2 with output LVDS-1 (none by udev)
[23:46:12.811] associating input device event3 with output LVDS-1 (none by udev)
[23:46:12.811] Output ‘LVDS-1’ enabled with head(s) LVDS-1
[23:46:12.811] Compositor capabilities:
arbitrary surface rotation: yes
screen capture uses y-flip: yes
cursor planes: yes
arbitrary resolutions: no
view mask clipping: yes
explicit sync: yes
color operations: no
presentation clock: CLOCK_MONOTONIC, id 1
presentation clock resolution: 0.000000001 s
[23:46:12.812] Loading module ‘/usr/lib/aarch64-linux-gnu/weston/desktop-shell.so’
[23:46:12.815] Loading module ‘/usr/lib/aarch64-linux-gnu/libweston-12/xwayland.so’
[23:46:12.911] Registered plugin API ‘weston_xwayland_v1’ of size 32
[23:46:12.911] Registered plugin API ‘weston_xwayland_surface_v1’ of size 16
[23:46:12.911] xserver listening on display :0
[23:46:12.912] Loading module ‘/usr/lib/aarch64-linux-gnu/weston/screen-share.so’
[23:46:12.914] launching ‘/usr/lib/aarch64-linux-gnu/weston-keyboard’
[23:46:12.923] launching ‘/usr/lib/aarch64-linux-gnu/weston-desktop-shell’
could not load cursor ‘dnd-move’
could not load cursor ‘dnd-copy’
could not load cursor ‘dnd-none’
could not load cursor ‘dnd-move’
could not load cursor ‘dnd-copy’
could not load cursor ‘dnd-none’
Hi @Shadiez
I tested your steps on my side and I got exactly the same results.
Except that in my case, the screen is working as expected 
Can I also ask which carrier board you are using? And the version of it?
If you are using the DSI adapter, please also include its version.
I tested it on a Mallow V1.1A
About this, I checked with the team.
This is correct and the expected result.
You can refer to the DSI display datasheet, but this is actually an LVDS display with a DSI interface and a DSI-to-LVDS bridge.
I am using a Mallow V1.1B
Is there a way to check if everything it setup correctly? Like the initial setup?
My boss did the setup before giving up and handing the project over to me so maybe I am missing some packages?
Maybe there is a way I can factory reset it and start fresh?
The output I should be expecting is similar to this correct:
Right now the screen is on but nothing is visible.
Is there a way for me to mirror the DSI output to my hdmi output? If I can do this then my monitor can be used to test if the lcd hardware/connector is the issue or the code.
Hi @Shadiez
This is actually the only thing you need. And it is correct.
I don’t think this is going to help. All the packages and dependencies are already inside the container.
yes, this is the output result of running the weston-terminal in docker.
I think the easiest test to validate only the screen is to try writing something directly to the framebuffer.
dd if=/dev/urandom of=/dev/fb0 bs=1024 count=4096
This is going to draw a static random pattern on the screen.
If you still only see the backlight, maybe check the flat connections?
Hi @Shadiez
To use the HDMI, you just need to change the overlay to
Just double checked the hardware and it seems good.
I tried putting in the command you sent and this is what I got with no visual on device:
torizon@verdin-imx8mp-15337091:~$ dd if=/dev/urandom of=/dev/fb0 bs=1024 count=4096
dd: error writing ‘/dev/fb0’: No space left on device
4001+0 records in
4000+0 records out
4096000 bytes (4.1 MB, 3.9 MiB) copied, 0.0480077 s, 85.3 MB/s
Looks like there might be an error?
