Running a Weston container on torizon mit Weston-vivante container

I now want to run weston on a module with weston container (torizon-core-docker-evaluation-verdin-imx8mp-Tezi_6.5.0-devel-202312+build.20.container)
After installation of this image, I started with Working with Weston on Torizon OS | Toradex Developer Center. Accordingly for the first step I went to Setting up Displays with Torizon | Toradex Developer Center
We are using a FullHD monitor through hdmi, and it shows the “Portainer” screen. When we now start “Testing display and touch” and use

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 

it responds with “invalid reference format”. Same result when we do the optional

# docker pull torizon/weston-vivante:$CT_TAG_WESTON_VIVANTE

The variable $CT_TAG_WESTON_VIVANTE is not set, there is only a $CT_TAG_WESTON variable, which is set to “rc”.
How to continue from there?
We found that on this system a container named torizon-weston-1 is already running due to portainer, but how does this interfere with the description that we used?

Hi @BernhardG !

You are running a monthly release, which by definition is an under-development build that might diverge from the documentation. You can read more about release types on the article Embedded Linux Support Strategy | Toradex Developer Center.

Currently, on pre-production releases (monthlies and nightlies), you can use the stable tag 3.

If you want to use a production release of Torizon OS, please use the current quarterly release which is version 6.4.0 (6.5.0 is soon to be released).

The current stable major tag (3 ) should always be used unless there is a good reason to use the rc (release candidate). The about-to-be-released 6.5.0 quarterly will use 3* tags in the environment variables. The rc tag isn’t available for torizon/weston-vivante, but it is for torizon/weston-imx8 (Docker).

Best regards,

Hi Henrique,
I was using this image, because it contains the PREEMPT_RT patch, that we will need in this application rather sooner than later. The quarterly release does not provide this option.
When will this be available as stable release?
Tomorrow I will put the quarterly release onto the sytem and try again (although I doubt that my current problem is related to this)
Thank you
br Bernhard

Hi @BernhardG !

I missed this question from your initial message, sorry.
Although it is possible to have two instances of Weston running (see Multi-Display section of Working with Weston on Torizon OS | Toradex Developer Center), seems like you want to have a single Weston instance.

On Torizon OS, there is a service responsible for starting the bundled containers: docker-compose.service. You can stop (non-permanent) and/or disable it (permanent), so the containers are not started:

# sudo systemctl disable docker-compose.service
# sudo systemctl stop docker-compose.service

This is the same service that would start a set of containers that you bundle into your customization of Torizon OS using TorizonCore Builder.

Currently, we indeed do not release Torizon OS with PREEMPT_RT as a production release. And, as far as I can tell, this is not planned.

I will ask internally if there is any information I can add about this.

About the new (6.5.0) quarterly of Torizon OS: this was released yesterday. You can see it available here:

We did not have any intention to run two Weston containers. We just went according to the document “Working with Weston on Torizon OS”. It says:

To have a better understanding of this article, the following prerequisites are recommended:

We used the image with Weston Container installed, because we were told, that this is the favorite image to start with, if planning to work with weston. But with this image, it seems we can not follow the instructions in this article. Does it mean we should rather use an image without these evaluation containers, so that we can follow the description? Are we able to do all the settings that are furtheron in the description altough we are using the evaluation containers? Do we have full control and access to this container from within a container where we lateron deploy and run our vscode programs?
Thank you

Hi @BernhardG !

Within the prerequisites, we have:

In that article, the section Multi-Container Example Using Docker Compose shows how to stop all running containers:

docker stop $(docker ps -a -q)

On the other hand, stoping all containers could be explicitly listed in the original article you were following. I will bring this up internally as a possible improvement.

You can follow the instructions, but since the image you are using ( is a pre-release (under development), some stuff might break and this is expected. If you don’t want to mind such details, using a production release is recommended.

Yes. You can simply stop the evaluation containers (and permanently disable the docker-compose.service as said above) and you should be good to go.

I didn’t understand this question… could you please clarify? What do you mean by “full control and access”?

I just edited my previous message: it is indeed possible to have more than one Weston instance running and we even have examples for it. This is part of the Working with Weston on Torizon OS | Toradex Developer Center article, more specifically under the Multi-Display section.

Best regards,

We are coming from WindowsCE and are new to Linux. Therefore we always want to go the preferred Toradex way, which is supposed to be the easiest when coming from WinCE. I see a lot of problems and burdons through the docker system, but we are forced to do this, because this is the only way to be able to use the VSCode IDE, and use the long time supported toradex images. Now we do not yet understand docker completely, but it is clear, that different containers are running like different “boxes”. On the final firmware we need to be able to have full control over all settings of the system, including network, display and all other interfaces to the outside. In regards to the display, the customer will sometimes need to set up a different type of display. In the firmware we will have some presets prepared, and by switching to a different preset, the display settings have to be changed completely. The firmware will be running in a different container than the wayland/weston, but these settings have to be changed permanently. Therefore I have concerns, that it might be impossible to access and control these settings from within a different box.

In regards to PREEMPT_RT. You are saying that there will never be a released version of this. But we will need at least some real time performance. So that means we will finally never be able to use a released version of image, and whenever we have a problem, the answer will always be: we can not help, because you are not using a released image, and that will probably be the reason for your problems?
best regards

Hello @BernhardG,

We understand your concerns.

With Torizon OS you can run your application in docker containers on top of the OS itself. This gives you flexibility and freedom to choose what platform you want the container to be based on (example: Debian). As @henrique.tx explained earlier, it is possible to run multiple containers and also you can define dependencies between these containers (or services in docker-compose) through a docker-compose file.

On the final firmware we need to be able to have full control over all settings of the system, including network, display, and all other interfaces to the outside.

Regarding this: You can map devices into the services in the docker-compose file. Please see the details here: Compose file version 3 reference | Docker Docs. This makes it possible for you to access/control the devices you need from within the corresponding docker containers.
As a starting point, you can take a look into the sample docker-compose file with which the portainer application is brought up in this location: /var/sota/storage/docker-compose/docker-compose.yml in your Torizon image.

Regarding your question on PREEMPT_RT image, I believe my colleague @jeremias.tx will be able to help you here.

In regards to PREEMPT_RT. You are saying that there will never be a released version of this. But we will need at least some real time performance. So that means we will finally never be able to use a released version of image, and whenever we have a problem, the answer will always be: we can not help, because you are not using a released image, and that will probably be the reason for your problems?

Our real-time image is basically the same as the standard image but with the Linux PREEMPT_RT patch applied. We do very minimal testing on this variant image. We can’t really validate any further than this since when it comes to real-time requirements everyone differs.

That said we don’t do “official releases” for this real-time variant due to the difficulties with validating and testing a myriad of use-cases. Some users in my experience even start out thinking they need the PREEMPT_RT patch only to figure out later they could have just proceeded with the standard version.

In summary, while we do have nightly and monthly builds for PREEMPT_RT, we can not hold it to the same standards as our standard version which is why there is no “official release”. Now this is our current position at this time and things may change, though not in the near future most likely.

Best Regards,

During the weekend, we installed the new release 6.5.0 of torizon with evaluation (no Preempt_rt) and indeed the first step to run the wayland container was working now. Of course from the next on, it is not working as shown in the article. When starting the weston terminal, it brings up the long ID number, but the container is not shown under docker container ls. We can open a terminal on the graphic desktop by clicking on the left top.
Next problem is when looking at the next sentence, where we are supposed to download tests: ```
apt update && apt install libdrm-tests, the system tells us, that apt is not installed. Trying to install apt, should be easy (every linux comment starts with “of course you can…”, but we have not been able to find out how, and on one toradex page we found, that it would not work and it would not be the appropriate method to install apt ???
It seems, it will take us months before we can start writing our first line of code in this system…
So far we are only struggling with following toradex articles, which do not work as described.


Hi @BernhardG !

I understand you opened a terminal from the display of the module, right? By default, anything that is shown on your display will be running inside a container, therefore you will have no view/access (by default) of the other containers nor docker commands (talking about e.g. docker subcommands - container ls, ps, run, stop, compose, etc - and docker-compose). So what you are reporting is actually expected.

I suppose you are talking about the Display Output, Resolution and Timings section of, right? I just tried the lines in there from a Weston container and it worked. What I pasted below ran on my computer, but of course this being a container, you will get the same result on your module. Just to be clear, on your module, you won’t need the --platform=linux/arm64/v8 argument because the CPU architecture on Verdin iMX8M Plus is already ARM64.

$ docker run --rm -it --platform=linux/arm64/v8 --entrypoint=/bin/bash torizon/weston:3
root@2217eb069d05:/home/torizon# apt update && apt install libdrm-tests
Get:1 bookworm InRelease [151 kB]
Get:2 bookworm-updates InRelease [52.1 kB]
Get:3 bookworm-security InRelease [48.0 kB]
Get:4 testing InRelease [15.1 kB]
Get:5 bookworm/main armhf Packages [8497 kB]
Get:6 testing/main armhf Packages [28.1 kB]
Get:7 bookworm-updates/main armhf Packages [12.1 kB]
Get:8 bookworm-security/main armhf Packages [129 kB]
Fetched 8933 kB in 23s (395 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
7 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libdrm-etnaviv1 libdrm-exynos1 libdrm-tegra0
The following NEW packages will be installed:
  libdrm-etnaviv1 libdrm-exynos1 libdrm-tegra0 libdrm-tests
0 upgraded, 4 newly installed, 0 to remove and 7 not upgraded.
Need to get 103 kB of archives.
After this operation, 431 kB of additional disk space will be used.
Get:1 bookworm/main armhf libdrm-etnaviv1 armhf 2.4.114-1+b1 [12.4 kB]
Get:2 bookworm/main armhf libdrm-exynos1 armhf 2.4.114-1+b1 [12.4 kB]
Get:3 bookworm/main armhf libdrm-tegra0 armhf 2.4.114-1+b1 [9956 B]
Get:4 bookworm/main armhf libdrm-tests armhf 2.4.114-1+b1 [68.8 kB]
Fetched 103 kB in 6s (18.4 kB/s)
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/ line 78, <> line 4.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (Can't locate Term/ in @INC (you may need to install the Term::ReadLine module) (@INC contains: /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/arm-linux-gnueabihf/perl5/5.36 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl-base /usr/lib/arm-linux-gnueabihf/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at /usr/share/perl5/Debconf/FrontEnd/ line 7, <> line 4.)
debconf: falling back to frontend: Teletype
Selecting previously unselected package libdrm-etnaviv1:armhf.
(Reading database ... 11671 files and directories currently installed.)
Preparing to unpack .../libdrm-etnaviv1_2.4.114-1+b1_armhf.deb ...
Unpacking libdrm-etnaviv1:armhf (2.4.114-1+b1) ...
Selecting previously unselected package libdrm-exynos1:armhf.
Preparing to unpack .../libdrm-exynos1_2.4.114-1+b1_armhf.deb ...
Unpacking libdrm-exynos1:armhf (2.4.114-1+b1) ...
Selecting previously unselected package libdrm-tegra0:armhf.
Preparing to unpack .../libdrm-tegra0_2.4.114-1+b1_armhf.deb ...
Unpacking libdrm-tegra0:armhf (2.4.114-1+b1) ...
Selecting previously unselected package libdrm-tests.
Preparing to unpack .../libdrm-tests_2.4.114-1+b1_armhf.deb ...
Unpacking libdrm-tests (2.4.114-1+b1) ...
Setting up libdrm-etnaviv1:armhf (2.4.114-1+b1) ...
Setting up libdrm-tegra0:armhf (2.4.114-1+b1) ...
Setting up libdrm-exynos1:armhf (2.4.114-1+b1) ...
Setting up libdrm-tests (2.4.114-1+b1) ...
Processing triggers for libc-bin (2.36-9+deb12u3) ...
root@2217eb069d05:/home/torizon# modetest --help
usage: modetest [-acDdefMPpsCvrw]

 Query options:

        -c      list connectors
        -e      list encoders
        -f      list framebuffers
        -p      list CRTCs and planes (pipes)

 Test options:

        -P <plane_id>@<crtc_id>:<w>x<h>[+<x>+<y>][*<scale>][@<format>]  set a plane
        -s <connector_id>[,<connector_id>][@<crtc_id>]:[#<mode index>]<mode>[-<vrefresh>][@<format>]    set a mode
        -C      test hw cursor
        -v      test vsynced page flipping
        -r      set the preferred mode for all connectors
        -w <obj_id>:<prop_name>:<value> set property
        -a      use atomic API
        -F pattern1,pattern2    specify fill patterns

 Generic options:

        -d      drop master after mode set
        -M module       use the given driver
        -D device       use the given device

        Default is to dump all info.

Could you please explicitly share the steps you are taking?

I see that you are in touch via email with your account manager to get further help. I hope we are able to unblock you as soon as possible :slight_smile:

Best regards,