How to display video captured by OS08A20 camera via HDMI?

morita · September 16, 2025, 6:07am

Hello,
Could you please tell me how to display video captured by the OS08A20 camera via HDMI?

■ Environment

Board: i.MX95 Verdin
Camera: OS08A20
BSP: Official NXP BSP
https://www.nxp.com/webapp/Download?colCode=L6.6.23_2.0.0_MX95&appType=license
Command used:

GST_DEBUG=3 gst-launch-1.0 v4l2src device=/dev/video0 ! "video/x-raw,width=1920,height=1080,format=YUYV" ! videoconvert ! autovideosink

■ Result

0:00:00.083718541 916 0xaaaaf3247f20 ERROR GST_PIPELINE grammar.y:1138:gst_parse_perform_link: could not link v4l2src0 to videoconvert0, neither element can handle caps video/x-raw, width=(int)1920, height=(int)1080, format=(string)YUYV WARNING: erroneous pipeline: could not link v4l2src0 to videoconvert0, neither element can handle caps video/x-raw, width=(int)1920, height=(int)1080, format=(string)YUYV

If any additional information is needed, please let me know.
Thank you in advance!

ToradexAI · September 16, 2025, 6:07am

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?

I’m sorry, but as an AI Assistant knowledgeable about Toradex, I only have the ability to answer questions about Toradex software and hardware platforms that support Torizon.

Your question involves the i.MX95 Verdin with the official NXP BSP, which falls outside the scope of Toradex software support. The available documentation indicates that i.MX95 EVK documentation is under NDA and requires access through NXP’s Early Access program (1).

For questions about official NXP BSPs and non-Torizon implementations, I’d recommend:

Consulting NXP’s official documentation and support channels
Checking the NXP community forums for BSP-specific guidance
If you’re interested in using Torizon OS on supported Toradex hardware, I’d be happy to help with camera integration using GStreamer pipelines

If you have questions about using cameras with Torizon OS on supported Toradex modules, feel free to ask and I can provide guidance on GStreamer pipeline configuration (2)(3).

Best regards, Toradex AI Assistant.

morita · September 16, 2025, 8:16am

@ToradexAI

I’d appreciate it if you could explain the procedure for Torizon OS.

ToradexAI · September 16, 2025, 8:17am

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

Did you like my answer?

Camera Video Display via HDMI on Torizon OS

Here’s how to display video captured by a camera via HDMI using Torizon OS:

Hardware Setup

For the Verdin iMX8M Plus (which is the closest supported module to your i.MX95), HDMI output is available through the Verdin DSI to HDMI adapter(1). The default display interface for the Verdin family is MIPI DSI, commonly exposed through the Verdin DSI to HDMI adapter which is enabled by default(1).

Required Containers

You’ll need to launch three containers for camera usage with HDMI display(2):

Weston Container - for displaying the video image
Camera Container - for interfacing with camera drivers
GStreamer Container - for running the video pipeline

Container Setup Process

1. Launch Weston Container

First, launch the Weston container for HDMI display support(2):

# 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

(2)

2. Discover Video Capture Device

List the available video devices to identify your camera(2):

# ls /dev/video*

(2)

Use v4l2-ctl --list-devices to identify which device corresponds to your camera(2).

3. Launch GStreamer Container

Launch the GStreamer container with proper device access(2):

# docker run --rm -it -v /tmp:/tmp -v /var/run/dbus:/var/run/dbus -v /dev:/dev -v /sys:/sys \
    --device /dev/<video-device> \
    --device-cgroup-rule='c 226:* rmw' --device-cgroup-rule='c 199:* rmw' \
    <your-dockerhub-username>/<Dockerfile-name>

(2)

GStreamer Pipeline

Once inside the GStreamer container, use a pipeline like this(2):

## gst-launch-1.0 v4l2src device=</dev/video*> ! <capsfilter> ! fpsdisplaysink video-sink=waylandsink

(2)

For a basic camera display pipeline(3):

gst-launch-1.0 v4l2src device=/dev/video2 ! video/x-raw,width=1920,height=1080 ! fpsdisplaysink text-overlay=false video-sink=waylandsink sync=false -v

(3)

Hardware Access Requirements

The containers need specific bind mounts for camera and display access(2):

/dev - Access to devices attached to the system
/tmp - Interaction with Weston (GUI)
/sys - Access to kernel subsystems
/var/run/dbus - Access to system services

Display Configuration

For HDMI output on Verdin modules, ensure the appropriate device tree overlay is enabled. The default resolution with HDMI overlays is 1920x1080(1).

Best regards, Toradex AI Assistant.

morita · October 21, 2025, 10:21am

@ToradexAI

When I connect the OS08A20 camera to NXP’s i.MX8M Plus EVK board, I can successfully output the captured image to HDMI. However, when I connect the same OS08A20 camera to Toradex’s i.MX95 Verdin board, the captured image is not displayed via HDMI.

One clear hardware difference is that the i.MX8M Plus EVK board allows direct connection via a mini-SAS cable, while the i.MX95 Verdin board requires a CSI/DSI to mini-SAS adapter in between.

Could you please advise how I can verify whether the CSI/DSI to mini-SAS adapter is being correctly controlled or initialized?

ToradexAI · October 21, 2025, 10:22am

Verifying CSI Adapter Initialization on Verdin iMX95

Based on the available Toradex documentation, I can provide guidance on verifying CSI adapter functionality, though specific information about the iMX95 Verdin with Torizon OS is limited in the current sources.

Hardware Interface Verification

For Verdin modules, the CSI interface uses MIPI CSI-2 signals located in the “Reserved” class of the Verdin specifications (1). The interface supports:

Scalable data lane support, 1 to 4 Data Lanes (1)
Up to 1.5Gbps per lane, providing 1080p60 capability with all 4 lanes (1)
Supports 10Mbps data rate in low power modes (1)

Device Tree Overlay Configuration

For camera functionality on Verdin modules, you’ll need to ensure the appropriate device tree overlay is enabled. For supported Verdin modules, camera overlays are available (2):

For Verdin iMX8M Plus (as reference):

verdin-imx8mp_ov5640_overlay.dtbo for CSI Camera OV5640 (2)

For Verdin iMX95:

verdin-imx95_ov5640_overlay.dtbo for CSI Camera OV5640 (2)

Verification Steps

Check Device Tree Overlay Status

Verify if the camera overlay is properly loaded by checking the overlays.txt file (3):
```
cat /sysroot/boot/ostree/torizon-*/dtb/overlays.txt
```
(3)
List Available Video Devices

Check if the camera is detected by the system:
```
ls /dev/video*
v4l2-ctl --list-devices
```
Verify CSI Interface Pins

The CSI interface uses specific pin assignments. For reference, the Verdin iMX8M Mini uses these CSI signals (1):
- CSI_1_CLK_P/N for interface clock (1)
- CSI_1_D0_P/N through CSI_1_D3_P/N for data lanes (1)
- I2C_4_CSI_SCL/SDA for camera control (1)

Troubleshooting CSI Adapter Issues

Based on community discussions, CSI interface issues can be hardware-related (4). Some factors to consider:

Signal Integrity: Ensure proper differential pair matching and impedance control (4)
Power Supply Stability: Verify stable power supply to both the module and camera (4)
Adapter Compatibility: The CSI/DSI to mini-SAS adapter must be properly configured for your specific camera

Current Limitations

The available documentation indicates that specific support for iMX95 Verdin with custom camera adapters may require additional configuration not covered in the standard device tree overlays. The iMX95 support appears to be in early stages, as mentioned in community discussions (5).

For detailed verification of your CSI/DSI to mini-SAS adapter initialization, you may need to:

Check the adapter’s specific device tree configuration
Verify the adapter’s power and control signals
Confirm the MIPI CSI-2 lane mapping matches your camera requirements

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.

morita · October 21, 2025, 10:55am

@ToradexAI

Is it MIPI CSI or MIPI CSI-2?

ToradexAI · October 21, 2025, 10:56am

MIPI CSI-2 is the Correct Standard

Based on the Toradex documentation, it is MIPI CSI-2 that is used across Toradex hardware platforms.

Toradex Module Families Support MIPI CSI-2

The official documentation clearly states that Toradex modules support MIPI CSI-2(1):

Verdin module family: Provides one quad-lane MIPI CSI-2 interface on reserved pins(1)
Apalis module family: Provides MIPI CSI-2 interfaces on module-specific pins(1)
Colibri module family: Does not provide MIPI-CSI interfaces, but some SoMs like the Colibri iMX8X feature a MIPI CSI-2 interface(1)

Technical Specifications Confirm MIPI CSI-2

The datasheets consistently reference MIPI CSI-2:

Verdin iMX8M Plus

The Verdin iMX8M Plus datasheet specifies “MIPI Camera Serial Interface (MIPI CSI)” and details that it supports two quad lane MIPI CSI-2 interfaces(2). The features include:

MIPI CSI-2 specification V1.3(2)
MIPI D-PHY specification V1.2(2)
Scalable data lane support, 1 to 4 Data Lanes(2)

Colibri iMX8X

The Colibri iMX8X datasheet section on “Camera Serial Interface” explicitly states it supports one quad lane MIPI CSI-2 interface(3). The interface uses MIPI D-PHY as the physical layer and supports RGB, YUV, and RAW color space definitions(3).

Aquila Module Family

The Aquila Carrier Board Design Guide refers to the “Camera Serial Interface (CSI) from the Mobile Industry Processor Interface Alliance (MIPI)” and specifies that the interface uses MIPI D-PHY as a physical layer, which is part of the MIPI CSI-2 standard(4).

Industry Standard Clarification

The documentation also clarifies potential confusion: “In some parts of the NXP documentation, the term CMOS sensor interface (CSI) is used. It is important not to confuse this name with the interface standard MIPI/CSI-2, a serial camera interface”(3).

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.

morita · October 21, 2025, 10:58am

@ToradexAI

The board I’m using is the i.MX95 19x19 Verdin.

ToradexAI · October 21, 2025, 10:58am

Verdin iMX95 19x19 Module Support

Thank you for clarifying that you’re using the Verdin iMX95 19x19 module.

Current Support Status

Based on the available documentation, the Verdin iMX95 is a newer module in Toradex’s product line. The sources indicate that device tree overlays are available for this module, including camera support (1).

Available Device Tree Overlays for Verdin iMX95

For the Verdin iMX95, there is a pre-built device tree overlay available for camera functionality:

verdin-imx95_ov5640_overlay.dtbo for CSI Camera OV5640 (1)

Camera Interface Specifications

The Verdin module family provides one quad-lane MIPI CSI-2 interface on reserved pins (1). This interface should support your OS08A20 camera, though you may need to create a custom device tree overlay specific to that sensor.

Device Tree Overlay Process

To enable camera functionality on your Verdin iMX95, you’ll need to:

Choose or Create an Overlay: You can either use an existing overlay as a base or create a new one for the OS08A20 camera (2)
Compile the Overlay: Convert the source file to a .dtbo binary file (2)
Deploy the Overlay: Copy the compiled overlay to your system and enable it (2)

Limitations for Custom Cameras

Since the OS08A20 is not among the standard supported cameras (like the OV5640), you’ll likely need to create a custom device tree overlay that defines the proper:

Camera sensor configuration
MIPI CSI-2 lane mapping
I2C communication settings
Power management

Next Steps

For your specific OS08A20 camera integration, you would need to:

Create a device tree overlay based on the OV5640 example but adapted for OS08A20 specifications
Ensure proper MIPI CSI-2 lane configuration matches your camera requirements
Verify the CSI/DSI to mini-SAS adapter compatibility with the Verdin iMX95 interface

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.

morita · November 25, 2025, 6:40am

@ToradexAI
Thank you for your support.

I’m trying again to output images captured by the OS08A20 camera via HDMI, this time using TorizonOS.
I built the TorizonOS image with the following command(s):

$ repo init -u https://github.com/nxp-imx/imx-manifest.git` -b imx-linux-scarthgap -m imx-6.6.52-2.2.0.xml $ cd sources $ git clone https://github.com/torizon/meta-toradex-torizon.git -b scarthgap-7.x.y $ git clone https://github.com/uptane/meta-updater.git -b scarthgap $ ln -s sources/meta-toradex-torizon/scripts/setup-environment torizon-setup-environment $ MACHINE=imx95-19x19-verdin . torizon-setup-environment build $ bitbake torizon-docker`

Write on the board(eMMC).
$ uuu.exe -b emmc_all imx-boot-imx95-19x19-verdin-sd.bin-flash_all torizon-docker-imx95-19x19-verdin-7.0.0-devel-20250602173442+build.0.wic.zst*
*
I followed this reference:
meta-toradex-torizon/docs/README-nxp.md at scarthgap-7.x.y · torizon/meta-toradex-torizon

Linux boots successfully, but v4l2-ctl, media-ctl, and GStreamer are not installed on the system.
What did I do wrong?

ToradexAI · November 25, 2025, 6:41am

Missing Camera Tools in Torizon OS Build

The issue you’re experiencing is expected behavior for Torizon OS. The tools like v4l2-ctl, media-ctl, and GStreamer are intentionally not included in the base Torizon OS image because Torizon OS is designed to use containerized applications (1).

Torizon OS Container-Based Architecture

Torizon OS follows a container-first approach where multimedia applications run inside Docker containers rather than directly on the host system (1). This design provides:

Isolation: Applications run in sandboxed environments (1)
Hardware Access: Containers can access specific hardware devices through bind mounts and device rules (1)
Shared Resources: Multiple containers can interact with GUI and system services (1)

Required Containers for Camera Usage

To use cameras with Torizon OS, you need to run specific containers (1):

Weston Container - for GUI and display output
GStreamer Container - containing v4l2-ctl, media-ctl, and GStreamer tools

Hardware Access Requirements

Camera containers need specific bind mounts (1):

/dev - Access to devices attached to the system (1)
/tmp - Interaction with Weston (GUI) (1)
/sys - Access to kernel subsystems (1)
/var/run/dbus - Access to system services (1)

Next Steps for Camera Integration

Launch Weston Container for HDMI display support (1)
Use or Build a GStreamer Container that includes the camera tools you need (1)
Configure Device Tree Overlays for your OS08A20 camera (you’ll likely need a custom overlay since this isn’t a standard supported sensor) (2)

Device Tree Overlay for Verdin iMX95

For camera functionality, you can reference the available overlay for OV5640 as a starting point (3):

verdin-imx95_ov5640_overlay.dtbo (3)

You’ll need to create a similar overlay customized for the OS08A20 camera specifications.

The container-based approach means your Torizon OS build is working correctly - the multimedia tools are simply packaged differently than in traditional Linux distributions.

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.

morita · November 25, 2025, 7:32am

@ToradexAI
Please provide detailed instructions for the i.MX95 Evaluation Kit.

ToradexAI · November 25, 2025, 7:33am

Detailed Instructions for i.MX95 Evaluation Kit

Overview

The Toradex i.MX95 Verdin Evaluation Kit is designed to accelerate next-gen edge AI, automotive, industrial and medical applications (1). It’s powered by NXP®’s i.MX 95 applications processor and provides comprehensive features for camera integration and HDMI display output (1).

Hardware Specifications

Core Processing Power

CPU: NXP i.MX 95 with 6x Arm Cortex™-A55 cores at 1.8 GHz (1)
Microcontrollers: 1x Arm Cortex™-M7 at 800MHz, 1x Arm Cortex™-M33 at 333MHz (1)
Memory: 16GB LPDDR5 (32-bit) RAM (1)
Storage: 64GB eMMC Flash (1)

Camera Interface Capabilities

2x Quad Lane MIPI CSI-2 interfaces for camera connectivity (1)
Neural Processing Unit (NPU): 2x NPU Performance of i.MX 8M Plus (1)
Image Signal Processor (ISP): Yes, with HDR and advanced de-noising support (1)

Display and Connectivity

HDMI: Via Verdin DSI to HDMI Adapter (included in the kit) (1)
Display Interfaces: 1x Quad Lane MIPI DSI, 1x Dual Channel LVDS (1)
Ethernet: 1x 10 Gigabit, 1x 1000BASE-T1 Automotive Ethernet, 1x Gigabit with TSN (1)
Wi-Fi/Bluetooth: 2.4/5 GHz Dual-band 1x1 Wi-Fi 6 (802.11ax), Bluetooth 5.2 (1)

What’s Included in the Kit

The i.MX95 Verdin Evaluation Kit includes (1):

iMX95 Verdin Evaluation Kit Carrier Board
iMX95 Verdin Evaluation Kit SoM
Verdin Industrial Heatsink Type 1
M2-MAYA-W2 card Wi-Fi 6, Bluetooth 5.4
Verdin DSI to HDMI Adapter
Verdin DSI/CSI to mini SAS Adapter
12V/30W AC/DC Power Adapter with barrel plug

Camera Setup Instructions

Hardware Connection

Connect your OS08A20 camera to the Verdin DSI/CSI to mini SAS Adapter (included in the kit) (1)
Connect the adapter to the appropriate CSI interface on the carrier board
Connect the Verdin DSI to HDMI Adapter to your HDMI display (1)

Software Configuration for Torizon OS

Step 1: Launch Required Containers

For camera usage with HDMI display, you need to run multiple containers (2):

Launch Weston Container for Display:

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

Step 2: Identify Camera Device

Check available video devices:

ls /dev/video*
v4l2-ctl --list-devices

Step 3: Launch GStreamer Container

Run GStreamer container with device access:

docker run --rm -it -v /tmp:/tmp -v /var/run/dbus:/var/run/dbus -v /dev:/dev -v /sys:/sys \
    --device /dev/<video-device> \
    --device-cgroup-rule='c 226:* rmw' --device-cgroup-rule='c 199:* rmw' \
    <your-dockerhub-username>/<Dockerfile-name>

Step 4: Camera Display Pipeline

Basic GStreamer pipeline for camera display:

gst-launch-1.0 v4l2src device=/dev/video2 ! video/x-raw,width=1920,height=1080 ! fpsdisplaysink text-overlay=false video-sink=waylandsink sync=false -v

Device Tree Overlay Configuration

Available Overlays

For camera functionality on Verdin iMX95, there’s a pre-built overlay available:

verdin-imx95_ov5640_overlay.dtbo for CSI Camera OV5640 (2)

Custom Overlay for OS08A20

Since OS08A20 is not a standard supported sensor, you’ll need to create a custom device tree overlay based on the OV5640 example but adapted for OS08A20 specifications.

MIPI CSI-2 Interface Details

The Verdin module family provides one quad-lane MIPI CSI-2 interface on reserved pins (2). Key specifications:

MIPI CSI-2 specification V1.3
MIPI D-PHY specification V1.2
Scalable data lane support: 1 to 4 Data Lanes
Performance: Up to 1.5Gbps per lane, providing 1080p60 capability with all 4 lanes

Display Configuration

HDMI Output Setup

The i.MX95 Verdin EVK supports HDMI output through the included Verdin DSI to HDMI Adapter (1). The default resolution with HDMI overlays is 1920x1080.

Graphics Capabilities

Graphics Controller: 3D & 2D GPU: Arm Mali-G310 V2 with 2D/3D acceleration (1)
Video Decoder/Encoder: Yes (1)
2D/3D Acceleration: Yes (1)

Migration Path to Production

The evaluation kit provides a clear path to volume production (1):

Start with the i.MX95 Verdin EVK for development and prototyping
Scale to production with:
- Verdin iMX95 SoM (Available Q2’2025)
- Aquila iMX95 SoM (Available Q3’2025)
- SMARC iMX95 SoM (Available Now)

Software Ecosystem Support

The i.MX95 Verdin EVK comes with comprehensive software support (1):

Torizon OS: Industrial Linux distribution with automotive-grade OTA updates
Container-first architecture: Applications run in isolated Docker containers
Security compliance: Helps with EU Cyber Resilience Act (CRA) requirements
Long-term support: Available until 2035+

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.

morita · November 26, 2025, 2:59am

@ToradexAI

I executed Step 1.

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” –device-cgroup-rule=“c 10:* rmw” torizon/weston-imx95:4 –developer

But the container did not start. Therefore, I cannot run “Check available video device” inside the container.

torizon@imx95-19x19-verdin:~$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
873788d9e12d torizon/weston-imx95:4 “/usr/bin/entry.sh -…” 4 minutes ago Exited (1) 4 minutes ago weston
torizon@imx95-19x19-verdin:~$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
torizon/weston-imx95 4 a8843f26b5f2 5 weeks ago 721MB

ToradexAI · November 26, 2025, 2:59am

Weston Container Startup Issue on Verdin iMX95

The Weston container is failing to start. Let’s troubleshoot this step by step.

Step 1: Check Container Logs

First, check the logs to see why the container failed to start:

docker logs weston

(1)

Step 2: Use Correct Container Image

For the Verdin iMX95, you should use the correct Weston container. Based on the documentation, the proper command for iMX95 is(2):

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" \
    --device-cgroup-rule="c 10:* rmw" \
    torizon/weston-imx95:4 \
    --developer

(2)

Step 3: Remove Failed Container

Before trying again, remove the failed container:

docker rm weston

Step 4: Check Video Devices from Host

You can check available video devices directly from the host system without needing the container running:

ls /dev/video*

(3)

Step 5: Alternative Container Approach

If the iMX95-specific container continues to fail, you might need to try a different approach. Based on community discussions, there have been issues with Weston containers on newer modules(4).

Step 6: Device-Specific Considerations

For the iMX95, ensure that:

Device Tree Overlays are properly configured for your display output(5)
Hardware Access Rules are correctly set for the specific hardware(1)
Display Interface is properly initialized (DSI to HDMI adapter)(5)

Troubleshooting Tips

The device cgroup rules in your command need to be properly formatted. Make sure you’re using the exact syntax from the documentation(1):

Use --device-cgroup-rule="c 4:* rmw" (with equals sign and quotes)
Ensure all backslashes for line continuation are properly placed
Check that the container image torizon/weston-imx95:4 is available and correct

Hardware Access Requirements

The Weston container needs specific hardware access(3):

/dev - Access to devices attached to the system
/tmp - Interaction with Weston (GUI)
/run/udev/ - Access to udev for hardware detection

Once you get the container logs, we can better diagnose the specific issue preventing the Weston container from starting.

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.

morita · November 26, 2025, 3:57am

@ToradexAI

The issue with the container not starting has not been resolved. I will share the result of running docker logs weston.

torizon@imx95-19x19-verdin:~$ docker logs weston
Switching VT tty1 to text mode if currently in graphics mode
Switching to VT 7
SoC is: ‘i.MX95’
SoC has GPU: true
SoC has DPU: true
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-11-26 UTC
[03:40:15.226] weston 12.0.4

Bug reports to: Making sure you're not a bot!
Build: 12.0.4
[03:40:15.226] Command line: weston -Bdrm-backend.so -Swayland-0
[03:40:15.226] OS: Linux, 6.6.52-lts-next-ge0f9e2afd4cf, #1-Torizon SMP PREEMPT Tue Nov 19 23:01:49 UTC 2024, aarch64
[03:40:15.226] Flight recorder: enabled
[03:40:15.227] Using config file ‘/etc/xdg/weston-dev/weston.ini’
[03:40:15.227] Output repaint window is 7 ms maximum.
[03:40:15.227] Loading module ‘/usr/lib/aarch64-linux-gnu/libweston-12/drm-backend.so’
[03:40:15.244] initializing drm backend
[03:40:15.245] Trying libseat launcher…
00:00:00.034 [INFO] [seatd/server.c:145] New client connected (pid: 28, uid: 1000, gid: 1000)
00:00:00.035 [INFO] [seatd/seat.c:170] Added client 7 to seat0
00:00:00.035 [INFO] [seatd/seat.c:480] Opened client 7 on seat0
[03:40:15.245] [libseat/libseat.c:73] Seat opened with backend ‘seatd’
[03:40:15.245] [libseat/backend/seatd.c:212] Enabling seat
[03:40:15.245] libseat: session control granted
[03:40:15.248] using /dev/dri/card0
[03:40:15.248] DRM: supports atomic modesetting
[03:40:15.248] DRM: supports GBM modifiers
[03:40:15.248] DRM: does not support async page flipping
[03:40:15.248] DRM: supports picture aspect ratio
[03:40:15.249] failed to initialize egl
00:00:00.039 [INFO] [seatd/seat.c:418] No clients on seat0 to activate
00:00:00.039 [INFO] [seatd/seat.c:524] Closed client 7 on seat0
00:00:00.039 [INFO] [seatd/seat.c:192] Removed client 7 from seat0
00:00:00.039 [INFO] [seatd/client.c:471] Client disconnected
[03:40:15.250] fatal: failed to create compositor backend
Internal warning: debug scope ‘drm-backend’ has not been destroyed.
00:00:00.049 [INFO] [seatd/seatd.c:218] seatd stopped
Switching back to vt 1

ToradexAI · November 26, 2025, 3:58am

EGL Initialization Failure on Verdin iMX95

The logs show that Weston is failing with an EGL initialization error: failed to initialize egl (1). This is a common issue with GPU initialization on newer modules.

Root Cause Analysis

The error indicates that the DRM backend cannot initialize the EGL (OpenGL ES) context. This typically happens when:

GPU drivers are not properly loaded
Hardware acceleration is not available
Device permissions are incorrect

Solution: Use Software Rendering

For the Verdin iMX95, you should try running Weston with software rendering instead of hardware acceleration. Based on the documentation for similar issues on other modules, use the --use-pixman flag (1):

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" \
    --device-cgroup-rule="c 10:* rmw" \
    torizon/weston-imx95:4 \
    --developer -- --use-pixman

(1)

Alternative: Check GPU Device Access

The logs show Weston is trying to use /dev/dri/card0. Verify the GPU device is accessible:

ls -la /dev/dri/

Device-Specific Considerations

For the iMX95, ensure that:

Display overlay is enabled for your HDMI output via the DSI to HDMI adapter
GPU drivers are properly initialized in your custom Torizon build
Hardware acceleration support is available for the Mali GPU

Troubleshooting Steps

Remove the failed container:
```
docker rm weston
```
Try with software rendering using the command above
Check if display devices are available:
```
ls /dev/dri/
ls /dev/fb*
```

Expected Behavior

With software rendering (--use-pixman), Weston should start successfully, though without hardware acceleration. This is similar to how other modules handle GPU initialization issues (1).

The EGL failure suggests that the Mali GPU drivers may not be fully initialized in your custom Torizon build for the iMX95, which is why software rendering is the recommended fallback approach.

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.

morita · November 26, 2025, 4:16am

@ToradexAI

The container has started successfully. However, the v4l2-ctl command is not available inside the container.

ToradexAI · November 26, 2025, 4:16am

Weston Container Doesn’t Include Camera Tools

That’s correct and expected behavior. The Weston container only provides the display compositor, not camera tools (1). For camera functionality on Torizon OS, you need to use separate containers for different functions (1).

Container Architecture for Camera Usage

Torizon OS uses a three-container approach for camera applications (1):

Weston Container - GUI/display compositor (which you now have running)
isp-imx Container - Camera driver interface
GStreamer Container - Video processing and tools like v4l2-ctl

Check Video Devices from Host System

You can check available video devices directly from the host system without needing them inside containers (1):

ls /dev/video*

(1)

Build Required Containers

For camera functionality, you need to build specific containers that include the camera tools. The documentation shows you need to build containers with the required packages (1):

For GStreamer container, you need packages like (2):

v4l-utils (which includes v4l2-ctl)
gstreamer1.0-tools
gstreamer1.0-plugins-*

Example Container Build Process

Based on the Toradex examples, you would create a Dockerfile that includes (2):

RUN apt-get -y update && apt-get install -y --no-install-recommends \
        libgstreamer1.0-0 \
        gstreamer1.0-plugins-base \
        gstreamer1.0-plugins-good \
        gstreamer1.0-plugins-bad \
        gstreamer1.0-plugins-ugly \
        gstreamer1.0-libav \
        gstreamer1.0-tools \
        v4l-utils \
        && apt-get clean && apt-get autoremove && rm -rf /var/lib/apt/lists/*

(2)

Next Steps

Build a GStreamer container with camera tools included
Launch the container with proper device access for your camera
Use the container to run v4l2-ctl and GStreamer pipelines

The separation of concerns means each container has a specific purpose - Weston for display, and separate containers for camera processing (1).

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.