I am trying to migrate a system which is currently uses Apalis T30 and WEC 2013 to Apalis IMX8 and Torizon. I managed to get my LVDS 6.5 inch 640x480 display to work with an additional device tree overlay. The screen is crisp and clear on startup but the fonts on the portainer login screen is almost unreadable. But thats only an minor problem. I wrote a little application as proof of concept that displays a moving map and some softkeys/menus and testet it using VS Code and WSL on a Windows host. Then i created a torizon project based on my cmake project with the torizon extension in VS Code. I builds successful but does not run on the target because some .png files for icons where not found. Meanwhile i have read the whole torizon documentation an found a litte hint that files the application is dependend on should be put under *appconfig_0/work/ . I did that and the files where deployed to /home/torizon/MFD_Torizon
torizon@apalis-imx8-07278737:~/MFD_Torizon$ ls
LeftEncBg.png bin button.bmp icao.png
torizon@apalis-imx8-07278737:~/MFD_Torizon$ pwd
/home/torizon/MFD_Torizon
So i put this path in to my source code where the images are loaded:
The result is: “error message: Failed to open file “/home/torizon/MFD_Torizon/icao.png”: No such file or directory”
So i guessed it is because the app is running in a container which has no access to that path. But why is it deployed there when i have no access? I added “/home/torizon/MFD_Torizon" under Volumes but that did not help.
Meanwhile i hate this whole Container/Docker overhead which makes things so confusing and obfuscates anything. I would really appreciate having a decent cross compiling setup in VS Code or VS Studio with a remote debugging client running on the target. But that only as a side note…
Maybe you can help me what is the right way to know in which path my application is running so it can have access to its data files. Of course this path should be static, nonvolatile and accessible in an easy way.
I believe the issue here is you’re passing the file path as it is outside of the container. But your application is inside the container and can only see file paths inside the container. That is to say you need to provide the file path for this file as it exists inside the container.
Now I understand /home/torizon/MFD_Torizon/icao.png is being bind-mounted as a volume inside the container so it should exist in there somewhere. But it might be a matter of the container path being slightly different. It’s also not clear to me from your initial information where this would be either.
While your container is running you can get a shell into your container with docker exec -it <container name/ID> bash. Then you can inspect the container filesystem and determine what’s the “right” file path.
thanks for your fast answer. After finding a way to copy the long container name/ID from docker ps (unfortunately you cannot copy it from Torizon Extension/Devices/Containers list) I did what you supposed and it turned out the directory on the target inside the container is just “/MFD_Torizon“ (despite I set a Volume to /home/torizon/MFD_Torizon ). With that I could load the image files and the software runs until it waits inside gtk_main(), but nothing is displayed (The Portainer screen is still visible but stuck, no input possible) The same program works when I compile it under WSL…
Looking at the Torizon Extension Container List (see screenshot below) I noticed that there is a _weston1 container with the same ID as my container but it is not started. I tried to start it manually but nothing happened.
BTW: I am very unhappy with this container stuff, it is so unhandy (imagine you have to deal with container names like “mfd_torizon_arm64v8-wayland-base-vivante-no-ssh_bullseye_debug_746dda42-7758-42f1-8631-5e34569a597f_latest_instance”, cannot even copy it and have to know docker commands just to find out where your application directory is…) and there is happening so much that is totally out of my control. Does any embedded systems developer like that ? – I don’t believe it. So if you have an idea how I can use a plain linux without having to build anything from scratch please advise…
Ok let’s try this, stop and remove all other containers not related to your application. Ensure nothing else is running that might conflict or interfere with your application. Once this is done, deploy and run your application again. Does the same thing happen still?
Looking at the Torizon Extension Container List (see screenshot below) I noticed that there is a _weston1 container with the same ID as my container but it is not started. I tried to start it manually but nothing happened.
How exactly are you running this Weston container?
OK, I removed all containers except my application and then it runs with display output. But two things are strange:
Initially under Torizon Extension/Devices/Containers my container is still marked as not running. The refresh button in the container headline does not change that. Only after tapping the refresh button in the device headline this changes and my container and a …weston_1 container are listed as running
The display color setting is wrong. It is OK during boot (shows my splash screen and the mouse arrow correctly) or when no container is running but in my application the colors are wrong, it looks like this:
The colors are also wrong when the portainer login screen is displayed
So I think the Weston container is started with a wrong color setting. My display uses JEIDA 24, maybe it is set to VESA 24 which would mix up the colors. The question for me is now: Where is the weston_1 container started and where can I see/change the display settings ?
Or more generally: why did the other containers disturb my app or who decides which container is displayed actually ?
Hmm this sounds strange to me. Usually the display settings including color are taken from the device tree for everything. I haven’t heard a case before where only one particular component (Weston) has incorrect color format, but everything else is fine.
Just to confirm you are certain it’s only Weston where the colors are bad? If that is the case and you are sure, then there does seem to be an option in the weston.ini configuration file to tune some color format: weston-drm(7) — Arch manual pages
Though to be honest I’ve never had to use this option before so I can’t provide any more details than what the linked document has. You can override the default weston.ini by using a volume/bind-mount to mount your own weston.ini to the correct spot in the Weston container. See more details here: Working with Weston on Torizon OS | Toradex Developer Center
Or more generally: why did the other containers disturb my app or who decides which container is displayed actually ?
It can be an issue when multiple containers are trying to use the same sub-systems (like graphics). This is because for the most part containers do not know about other containers by default. As for what decided the priority on what gets displayed, as far as I’m aware there’s no explicit priority or such. It might be just whatever was using the display sub-system first. But, this is why I suggested to stop the other containers first to avoid any possible noise or interference that could occur.
I tried to do what you suggested but I cannot get the weston container to run via command line. It is created but not started. Manual start does not work, if I try to start a shell it says “container not running”
I tried a lot of versions of the “Docker run …” command but nothing works. It seems that I cannot just “bind mount” the directory with your test picture to a running container
Looking at the screenshot for Portainer you provided. I honestly can’t tell whether the colors are actually off or not, or whether it’s the color balance of the camera.
This looks like a color mapping problem. Most probably you will have to change it through your device tree overlay.
Here you can find documentation about this topic.
OK, finally I figured it out: I created the device tree overlay with my custom baseboard in mind which sets the LVDS display to Jeida-24. But for testing I used the display with an ixora board and a cable which sets jeida-18 mode. After changing lvds-channel@0 and the display data-mapping to 18 it works…
