Tutorial Error on How to use Cameras on Torizon

Emmanouil · January 7, 2025, 9:02am

Hi,

I am going through the tutorial in How to use Cameras on Torizon | Toradex Developer Center and I face an issue when I try to build the container image for a VPU accelerated iMX8 SoM (Verdin iMX8M Plus) with:

$ docker build --build-arg BASE_NAME=wayland-base-vivante --build-arg IMAGE_ARCH=arm64/v8 -t <your-dockerhub-username>/gst_example .

The error I am facing is related to a missing public key in your repo and can be seen below:

I tried to resolve it by adding the missing GPG key by including the following command in my Dockerfile but this ultimately failed to solve the problem:

RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 116A149EBBC0779B

Could you please help me solve this issue?

Thank you in advance.

ToradexAI · January 7, 2025, 9:03am

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

Hello,

Thank you for reaching out with your issue. It seems you’re encountering a problem with a missing GPG key while building a Docker container image for your Verdin iMX8M Plus on Torizon. Here are some steps you can try to resolve this:

Verify the Repository URL: Double-check that the repository URL in your Dockerfile is correct and accessible. Sometimes URLs can change or be temporarily unavailable.
Ensure the Correct GPG Key: The GPG key you attempted to add might not match the repository. Verify the correct key from the repository’s documentation and add it using:
```
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys <correct-key-id>
```
Replace <correct-key-id> with the actual key ID.
Update the Package List: After adding the GPG key, make sure to update the package list:
```
RUN apt-get update
```
Check Network Connectivity: Ensure your build environment has internet access and can reach the keyserver and repository URLs.
Try a Different Keyserver: If the current keyserver is unresponsive, try using another one, such as hkp://keyserver.ubuntu.com:80.

These steps should help you resolve the issue and successfully build your container image. If the problem persists, review your Dockerfile for any other potential misconfigurations.

I hope this helps!

Best regards,
Toradex AI Assistant.

Please, also check if these links can help you solve your problem:

Public key not available when trying to run torizon QT frontend in docker container.

bruno.tx · January 7, 2025, 11:38am

Hello @Emmanouil,

Welcome to the Toradex Community!

I tried to reproduce the error here and could not get this same error on step 8 of the build process.
Can you check if the system time is synchronized properly?

If it is, building without a cache may help to solve this issue:

docker build --pull --no-cache --build-arg BASE_NAME=wayland-base-vivante --build-arg IMAGE_ARCH=arm64/v8 -t <your-dockerhub-username>/gst_example .

It is important to bring up that despite the fact that I had no issues with the public key, step 9 of the build process still failed.
Therefore, to build the image with the VPU libraries some changes need to be made to the sample.
I am looking into which changes are needed and will send an update here as soon as I get this working.

Best Regards,
Bruno

Emmanouil · January 7, 2025, 12:14pm

Hi Bruno and thanks for your quick response!

I managed to fix the step 8 issue, I think it was related to having the wrong ARGs at the beginning of the Dockerfile.

I managed to reach up to step 16 on my machine where the following command runs:

RUN git clone https://github.com/nxp-imx/imx-gst1.0-plugin.git \
        -b MM_04.08.03_2312_L6.6.y \
    && cd imx-gst1.0-plugin \
    && meson -Dplatform=MX8 --prefix=/usr --libdir=/usr/lib/aarch64-linux-gnu \
        -Dc_args="-I/usr/include -I/usr/include/imx"  build \
    && ninja -v -j$(nproc) -C build \
    && DESTDIR=/vpusysroot ninja -v -j$(nproc) -C build install \
    && cp -r /vpusysroot/* / \
    && cd .. && rm -rf imx-gst1.0-plugin

There I encountered a new error, which I think is related to the nxp repo. Specifically, several files fail to compile due to missing header files, such as:

gstimxcommon.h
gst/allocators/gstphymemmeta.h
gst/allocators/gstdmabufmeta.h
gst/allocators/gstallocatorphymem.h

Unfortunately, I cannot yet upload the exact error since it is rather big and I am not allowed to upload files as a new user. I checked that the branch that is used from nxp is actually quite old. Could it be that this branch is no longer maintained or a new version of the imx-gst1.0-plugin needs to be used instead?

Thank you in advance!

bruno.tx · January 7, 2025, 12:20pm

Hello @Emmanouil,

I am currently looking into this exact error.
It is still unclear why such error is present as I built this sample a few months ago without issues.
Regardless, I will keep looking into possible solutions.

The MM_04.07.02_2210_L5.15.y branch is the latest for the NXP BSP using the Linux Kernel 5.15, which is used in Torizon OS 6.
Updating the branches of the NXP libraries may lead to incompatibility with Torizon OS 6.

Best Regards,
Bruno

bruno.tx · January 7, 2025, 1:29pm

Hello @Emmanouil,

The problem was related to the version of the pinned packages.
Can you try again using the following version-pinned-packages file?
version-pinned-packages (2.5 KB)

I also opened a Pull-Request on the Torizon Samples Repository to get this fixed: vpu: vpuGeneric: Pin Dependency Packages to Version 1.20 by brunoaamello · Pull Request #35 · toradex/torizon-samples · GitHub

It should be merged soon.

Best Regards,
Bruno

Emmanouil · January 7, 2025, 3:41pm

Dear Bruno,

Unfortunately even after following your recommended change I still get errors in step 16.You can see below the last snippet of the error:

101.1 ../plugins/aiurdemux/aiurdemux.c: In function ‘aiurdemux_check_buffer_sending_status’:
101.1 ../plugins/aiurdemux/aiurdemux.c:3973:33: warning: format ‘%s’ expects a matching ‘char *’ argument [-Wformat=]
101.1  3973 |           GST_LOG_OBJECT(demux, "pad: %s, buffering position is invalid");
101.1       |                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
101.1 /usr/include/gstreamer-1.0/gst/gstinfo.h:727:31: note: in definition of macro ‘GST_CAT_LEVEL_LOG’
101.1   727 |         (GObject *) (object), __VA_ARGS__);                             \
101.1       |                               ^~~~~~~~~~~
101.1 ../plugins/aiurdemux/aiurdemux.c:3973:11: note: in expansion of macro ‘GST_LOG_OBJECT’
101.1  3973 |           GST_LOG_OBJECT(demux, "pad: %s, buffering position is invalid");
101.1       |           ^~~~~~~~~~~~~~
101.1 ../plugins/aiurdemux/aiurdemux.c:3973:40: note: format string is defined here
101.1  3973 |           GST_LOG_OBJECT(demux, "pad: %s, buffering position is invalid");
101.1       |                                       ~^
101.1       |                                        |
101.1       |                                        char *
101.1 ../plugins/aiurdemux/aiurdemux.c: In function ‘aiurdemux_push_pad_buffer’:
101.1 ../plugins/aiurdemux/aiurdemux.c:4000:27: warning: format ‘%d’ expects argument of type ‘int’, but argument 13 has type ‘gsize’ {aka ‘long unsigned int’} [-Wformat=]
101.1  4000 |   GST_DEBUG_OBJECT (demux,"%s push sample %" GST_TIME_FORMAT " size %d is discont: %d is delta unit: %d",
101.1       |                           ^~~~~~~~~~~~~~~~~~
101.1  4001 |       AIUR_MEDIATYPE2STR (stream->type),
101.1  4002 |       GST_TIME_ARGS (GST_BUFFER_TIMESTAMP (buffer)), gst_buffer_get_size (buffer), \
101.1       |                                                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
101.1       |                                                      |
101.1       |                                                      gsize {aka long unsigned int}
101.1 /usr/include/gstreamer-1.0/gst/gstinfo.h:727:31: note: in definition of macro ‘GST_CAT_LEVEL_LOG’
101.1   727 |         (GObject *) (object), __VA_ARGS__);                             \
101.1       |                               ^~~~~~~~~~~
101.1 ../plugins/aiurdemux/aiurdemux.c:4000:3: note: in expansion of macro ‘GST_DEBUG_OBJECT’
101.1  4000 |   GST_DEBUG_OBJECT (demux,"%s push sample %" GST_TIME_FORMAT " size %d is discont: %d is delta unit: %d",
101.1       |   ^~~~~~~~~~~~~~~~
101.1 ../plugins/aiurdemux/aiurdemux.c: In function ‘gst_aiurdemux_perform_seek’:
101.1 ../plugins/aiurdemux/aiurdemux.c:4182:47: warning: passing argument 3 of ‘IParser->seek’ from incompatible pointer type [-Wincompatible-pointer-types]
101.1  4182 |       IParser->seek(handle, stream->track_idx,&usSeekTime, SEEK_FLAG_NO_LATER);
101.1       |                                               ^~~~~~~~~~~
101.1       |                                               |
101.1       |                                               guint64 * {aka long unsigned int *}
101.1 ../plugins/aiurdemux/aiurdemux.c:4182:47: note: expected ‘uint64 *’ {aka ‘long long unsigned int *’} but argument is of type ‘guint64 *’ {aka ‘long unsigned int *’}
101.1 ../plugins/aiurdemux/aiurdemux.c:4217:11: warning: passing argument 3 of ‘IParser->seek’ from incompatible pointer type [-Wincompatible-pointer-types]
101.1  4217 |           &usSeekTime, SEEK_FLAG_NO_LATER);
101.1       |           ^~~~~~~~~~~
101.1       |           |
101.1       |           guint64 * {aka long unsigned int *}
101.1 ../plugins/aiurdemux/aiurdemux.c:4217:11: note: expected ‘uint64 *’ {aka ‘long long unsigned int *’} but argument is of type ‘guint64 *’ {aka ‘long unsigned int *’}
101.1 ../plugins/aiurdemux/aiurdemux.c:4240:17: warning: passing argument 3 of ‘IParser->seek’ from incompatible pointer type [-Wincompatible-pointer-types]
101.1  4240 |                 &usSeekTime, SEEK_FLAG_NO_LATER);
101.1       |                 ^~~~~~~~~~~
101.1       |                 |
101.1       |                 guint64 * {aka long unsigned int *}
101.1 ../plugins/aiurdemux/aiurdemux.c:4240:17: note: expected ‘uint64 *’ {aka ‘long long unsigned int *’} but argument is of type ‘guint64 *’ {aka ‘long unsigned int *’}
101.1 ../plugins/aiurdemux/aiurdemux.c: At top level:
101.1 ../plugins/aiurdemux/aiurdemux.c:3132:1: warning: ‘_gst_buffer_copy_into_mem’ defined but not used [-Wunused-function]
101.1  3132 | _gst_buffer_copy_into_mem (GstBuffer * dest, gsize offset, const guint8 * src,
101.1       | ^~~~~~~~~~~~~~~~~~~~~~~~~
101.6 [42/47] cc  -o tools/grecorder/librecorder_engine-1.0.so.0.0.0 tools/grecorder/librecorder_engine-1.0.so.0.0.0.p/recorder_engine.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,
-soname,librecorder_engine-1.0.so.0 /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so /usr/lib/aarch64-linux-gnu/libgobject-2.0.so /usr/lib/aarch64-linux-gnu/libglib-2.0.so /usr/lib/aarch64-linux-gnu/libgstbase-1.
0.so /usr/lib/aarch64-linux-gnu/libgstvideo-1.0.so -lgstpbutils-1.0 -Wl,--end-group
101.6 FAILED: tools/grecorder/librecorder_engine-1.0.so.0.0.0
101.6 cc  -o tools/grecorder/librecorder_engine-1.0.so.0.0.0 tools/grecorder/librecorder_engine-1.0.so.0.0.0.p/recorder_engine.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,
librecorder_engine-1.0.so.0 /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so /usr/lib/aarch64-linux-gnu/libgobject-2.0.so /usr/lib/aarch64-linux-gnu/libglib-2.0.so /usr/lib/aarch64-linux-gnu/libgstbase-1.0.so /us
r/lib/aarch64-linux-gnu/libgstvideo-1.0.so -lgstpbutils-1.0 -Wl,--end-group
101.6 /usr/bin/ld: tools/grecorder/librecorder_engine-1.0.so.0.0.0.p/recorder_engine.c.o: in function `add_time_stamp':
101.6 /imx-gst1.0-plugin/build/../tools/grecorder/recorder_engine.c:1763: undefined reference to `IS_IMX95'
101.6 collect2: error: ld returned 1 exit status
102.1 [43/47] cc  -o plugins/aiurdemux/libgstaiurdemux.so plugins/aiurdemux/libgstaiurdemux.so.p/aiur.c.o plugins/aiurdemux/libgstaiurdemux.so.p/aiurregistry.c.o plugins/aiurdemux/libgstaiurdemux.so.p/aiurstrea
mcache.c.o plugins/aiurdemux/libgstaiurdemux.so.p/aiuridxtab.c.o plugins/aiurdemux/libgstaiurdemux.so.p/aiurdemux.c.o plugins/aiurdemux/libgstaiurdemux.so.p/aiurtypefind.c.o plugins/aiurdemux/libgstaiurdemux.so
.p/aiurcontent.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libgstaiurdemux.so '-Wl,-rpath,$ORIGIN/../../libs' -Wl,-rpath-link,/imx-gst1.0-plugin/build/libs libs/libgstfsl-
1.0.so.0.0.0 -ldl /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so /usr/lib/aarch64-linux-gnu/libgobject-2.0.so /usr/lib/aarch64-linux-gnu/libglib-2.0.so /usr/lib/aarch64-linux-gnu/libgstbase-1.0.so -lgsttag-1.0
-lgstriff-1.0 -Wl,--end-group
104.3 [44/47] cc -Iplugins/spdifdemux/libgstspdifdemux.so.p -Iplugins/spdifdemux -I../plugins/spdifdemux -I../ext-includes -Ilibs -I../libs -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib/aarch6
4-linux-gnu/glib-2.0/include -I/usr/include/aarch64-linux-gnu -I/usr/include/imx-mm/parser -I/usr/include -I/usr/include/imx -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O0 -g -U_FILE_
OFFSET_BITS -DARM -D_GUNC_ -fPIC -pthread '-DVERSION="4.8.3"' '-DPACKAGE="imx-gst1.0-plugin"' -O2 -fno-omit-frame-pointer -D_ARM12 -MD -MQ plugins/spdifdemux/libgstspdifdemux.so.p/gstspdifdemux.c.o -MF plugins/
spdifdemux/libgstspdifdemux.so.p/gstspdifdemux.c.o.d -o plugins/spdifdemux/libgstspdifdemux.so.p/gstspdifdemux.c.o -c ../plugins/spdifdemux/gstspdifdemux.c
104.3 ninja: build stopped: subcommand failed.
------

 1 warning found (use docker --debug to expand):
 - StageNameCasing: Stage name 'Base' should be lowercase (line 22)
Dockerfile:161
--------------------
 160 |     # imx-gst1.0-plugin
 161 | >>> RUN git clone https://github.com/nxp-imx/imx-gst1.0-plugin.git \
 162 | >>>         -b MM_04.08.03_2312_L6.6.y \
 163 | >>>     && cd imx-gst1.0-plugin \
 164 | >>>     && meson -Dplatform=MX8 --prefix=/usr --libdir=/usr/lib/aarch64-linux-gnu \
 165 | >>>         -Dc_args="-I/usr/include -I/usr/include/imx"  build \
 166 | >>>     && ninja -v -j$(nproc) -C build \
 167 | >>>     && DESTDIR=/vpusysroot ninja -v -j$(nproc) -C build install \
 168 | >>>     && cp -r /vpusysroot/* / \
 169 | >>>     && cd .. && rm -rf imx-gst1.0-plugin
 170 |
--------------------
ERROR: failed to solve: process "/bin/sh -c git clone https://github.com/nxp-imx/imx-gst1.0-plugin.git         -b MM_04.08.03_2312_L6.6.y     && cd imx-gst1.0-plugin     && meson -Dplatform=MX8 --prefix=/usr --
libdir=/usr/lib/aarch64-linux-gnu         -Dc_args=\"-I/usr/include -I/usr/include/imx\"  build     && ninja -v -j$(nproc) -C build     && DESTDIR=/vpusysroot ninja -v -j$(nproc) -C build install     && cp -r /
vpusysroot/* /     && cd .. && rm -rf imx-gst1.0-plugin" did not complete successfully: exit code: 1

Best,
Emmanouil

bruno.tx · January 7, 2025, 3:50pm

Hello @Emmanouil,

Did you get this error while trying to build without a cache with the following command?

docker build --pull --no-cache --build-arg BASE_NAME=wayland-base-vivante --build-arg IMAGE_ARCH=arm64/v8 -t <your-dockerhub-username>/gst_example .

If not, which command did you use to build the container?

Best Regards,
Bruno

Emmanouil · January 7, 2025, 4:04pm

Hi @bruno.tx ,

I used the following command:

docker build --no-cache --build-arg BASE_NAME=wayland-base-vivante --build-arg IMAGE_ARCH=arm64/v8 -t <your-dockerhub-username>/gst_example .

Do you think that omitting the “–pull” option might make a difference?

Best,
Emmanouil

j.kugele · January 7, 2025, 5:08pm

Hi, as I also tried to follow the same article a few days ago, so I will share my steps here.
I am trying to get the camera AR0521 running with hardware encoding.
I also use a Verdin iMX8MP, on a Dahlia carrier board.

First I built Torizon OS 6.9.0 with the AR0521 camera Yocto overlay, but this gave me I2C errors on the boot console. Then I built 6.5.0 as this version was mentioned in a commit message of the overlay. With this the I2C errors went away.

Then I also struggled with building the Docker image for the camera. I also had the problem with version pinned packages, but on top the finally created image wouldnt run on the Verdin board because of “unsupported platform” errors.

While I dont know if it helps in this issue here, I can after 2 days now successfully run the gstreamer example which displays the raw camera stream in a Wayland window, so I am sharing the details:

Build environment: Windows 11 with WSL2 and Docker Desktop

Dockerfile and version-pinned file: As I am not allowed to upload files as a new user, I will post it as text on request. I heavily modified both files with Trial&Error to get the build done.

Build command for the Docker image (this command will try to immediately push the created image to the local Docker registry created by Torizon IDE extension):

docker buildx build --push --build-arg BASE_NAME=wayland-base-vivante --build-arg IMAGE_ARCH=arm64/v8 --platform linux/arm64/v8 . -t localhost:5002/gst_example

Command to run the docker images:

docker run -e MACHINE=verdin-imx8mp --rm -it -v /tmp:/tmp -v /var/run/dbus:/var/run/dbus -v /dev:/dev -v /sys:/sys \
    --device /dev/video2 \
    --device-cgroup-rule='c 226:* rmw' --device-cgroup-rule='c 199:* rmw' 192.168.0.201:5002/gst_example:latest /bin/bash

Command inside docker image to display the video window:

gst-launch-1.0 v4l2src device='/dev/video2' num-buffers=300 ! "video/x-raw, format=RGB16, framerate=30/1, width=1920, height=1080" ! fpsdisplaysink video-sink=waylandsink text-overlay=false sync=false

“/dev/video2” might need to be adjusted…

However I am not able to use the hardware video decoder encoder, I will open a thread about this next…

bruno.tx · January 8, 2025, 8:52am

Hello @Emmanouil,

It is possible that the lack of the --pull argument results in a different container, if you have an older version of the wayland-base-vivante container locally.

The pull request has been merged, so I would recommend that you try to build the container in a new environment, cloning the repository again:

git clone -b bookworm-new https://github.com/toradex/torizon-samples.git
cd torizon-samples/vpu/generic/vpuGeneric
docker build --pull --no-cache --build-arg BASE_NAME=wayland-base-vivante --build-arg IMAGE_ARCH=arm64/v8 -t <your-dockerhub-username>/gst_example .

Please give this a try and let me know if this works for you.

Hello @j.kugele,

Thanks for sharing your tests.
The “Unsupported platform” error is from the missing environment variable MACHINE, which should be set when running the VPU test scripts.

We will support you with the issue you reported on the respective thread.

Best Regards,
Bruno

Emmanouil · January 9, 2025, 9:43am

Hi @bruno.tx ,

While I managed to resolve all the issues with the build step, now I am facing issues when running the weston container as is instructed in the same tutorial with:

# 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

More specifically I see the following error when I inspect the logs of the container:

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-01-09 UTC
[09:13:39.893] weston 12.0.4
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: 12.0.4
[09:13:39.894] Command line: weston -Bdrm-backend.so --current-mode -Swayland-0 --use-g2d
[09:13:39.894] OS: Linux, 5.15.148-6.8.0+git.8c5c2dcbf6ba, #1-TorizonCore SMP PREEMPT Tue Aug 6 10:01:59 UTC 2024, aarch64
[09:13:39.894] Flight recorder: enabled
[09:13:39.894] Using config file '/etc/xdg/weston-dev/weston.ini'
[09:13:39.894] Output repaint window is 7 ms maximum.
[09:13:39.895] Loading module '/usr/lib/aarch64-linux-gnu/libweston-12/drm-backend.so'
[09:13:39.903] initializing drm backend
[09:13:39.903] Trying libseat launcher...
00:00:00.023 [INFO] [seatd/server.c:145] New client connected (pid: 29, uid: 1000, gid: 1000)
00:00:00.024 [INFO] [seatd/seat.c:170] Added client 7 to seat0
00:00:00.024 [INFO] [seatd/seat.c:480] Opened client 7 on seat0
[09:13:39.904] [libseat/libseat.c:73] Seat opened with backend 'seatd'
[09:13:39.904] [libseat/backend/seatd.c:212] Enabling seat
[09:13:39.904] libseat: session control granted
[09:13:39.909] using /dev/dri/card0
[09:13:39.909] DRM: supports atomic modesetting
[09:13:39.909] DRM: does not support GBM modifiers
[09:13:39.909] DRM: does not support async page flipping
[09:13:39.909] DRM: supports picture aspect ratio
[09:13:39.909] Loading module '/usr/lib/aarch64-linux-gnu/libweston-12/g2d-renderer.so'
g2d_open: fail with status -7
[09:13:39.920] g2d_open fail.
[09:13:39.920] g2d_renderer_create faile.
[09:13:39.920] failed to initialize g2d renderer
00:00:00.041 [INFO] [seatd/seat.c:418] No clients on seat0 to activate
00:00:00.041 [INFO] [seatd/seat.c:524] Closed client 7 on seat0
00:00:00.041 [INFO] [seatd/seat.c:192] Removed client 7 from seat0
00:00:00.041 [INFO] [seatd/client.c:471] Client disconnected
00:00:00.110 [INFO] [seatd/seatd.c:218] seatd stopped
Switching back to vt 1```
The log output indicates that the g2d renderer failed to initialize due to an error in the g2d_open function. From my research this might be due to likely the renderer requiring specific hardware or driver support that is either unavailable or misconfigured in the container or host environment. While I did some troubleshooting, I was not able to resolve it. 

I hope you can guide me on what might be going woring.

Thank you in advance.

bruno.tx · January 9, 2025, 9:57am

Hello @Emmanouil,

I see that you are using the command for Torizon OS 7, but the system is running Torizon OS 6.

The documentation for Torizon OS 6 is available here: How to use Cameras on Torizon | Toradex Developer Center

From there, you can use the following command to start Weston:

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

Another relevant point to bring here, is that the command to run the GStreamer container on the guide is not complete with all the permissions needed for VPU usage.
To run the GStreamer container with the VPU, you can use the following command:

docker run --rm -it -e MACHINE=verdin-imx8mp -v /tmp:/tmp -v /var/run/dbus:/var/run/dbus -v /dev:/dev -v /sys:/sys --device-cgroup-rule='c 226:* rmw' --device-cgroup-rule='c 199:* rmw' --device-cgroup-rule='c 81:* rmw' --device-cgroup-rule='c 234:* rmw' --device-cgroup-rule='c 235:* rmw' --device-cgroup-rule='c 253:* rmw' <container name>

Best Regards,
Bruno

Emmanouil · January 9, 2025, 1:39pm

Dear @bruno.tx ,

Thank you very much! Indeed that solved the issue.

I wanted to check with you also another point that is not that clear in the tutorial:

In the above instruction when trying to discover the video capture device, which “previously built container” does it refer to? I assumed the gst_example, but when I run the v4l2-ctl --list-devices command inside the container I get the response bash: v4l2-ctl: command not found.
Additionally, is it the expected response that all the tests in vputests.sh finish, then the gstreamer container stops by itself?

Kind regards,
Emmanouil

bruno.tx · January 9, 2025, 3:19pm

Hello @Emmanouil,

Your assumption is correct. What I think the issue is here is that the container from the sample does not include the v4l-utils package by default.
To use v4l2-ctl, this package is required.
Therefore, you could do one of the following:

Add v4l-utils to the packages that are installed at the end of the Dockerfile
Or install it when you are inside the container

To install it while inside the container, you can simply run the following command:

apt update && apt install -y v4l-utils

Yes, for the container with the VPU enablement the default entrypoint is the vputests.sh script.
To change this, you can either remove this from the Dockerfile or run the container with --entrypoint=bash.

Best Regards,
Bruno

Emmanouil · January 14, 2025, 12:29pm

Dear @bruno.tx,

Thank you very much for all your support. I can happily tell you that I managed to successfully run this demo without any further problems.

Best wishes,
Emmanouil

bruno.tx · January 14, 2025, 12:32pm

Hello @Emmanouil,

Thanks for the update, I am glad you were able to get this to work.

Best Regards,
Bruno