Hi, we have simple Qt application which uses weston-vivante:2 image.
When module is powered on weston-vivante starts differently. It may show the dark blue screen with mouse cursor for a short time and then our application starts in a full screen mode. But sometimes it provides a gray screen with the black background string on a top showing the date/time info on right and icon for wayland terminal launch on left. Here we can launch wayland terminal.
Our Qt application is also starts, but with this string on top. This happens after hardware reset as well. But if we use sudo reboot command from the console, weston:vivante always shows a dark blue screen.
We observed the same with Uno platform, but in this case Uno application does not start at all when the gray screen with the string on top appears. In the case with the dark blue, Uno works fine.
Below slp2.yml for Uno and smartlogpro2.yml for Qt.
Thank you.
slp2.yml (1.4 KB)
smartlogpro2.yml (1.4 KB)
Greetings @Serghey
With regards to the 2 different displays with Weston let me explain. This is the command to launch the weston-vivante container from our Debian Containers for Torizon | Toradex Developer Center article.
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 weston-launch \
--tty=/dev/tty7 --user=torizon
If you run this command as is, you get the gray screen. If you run the command without the --developer flag you get the dark blue screen.
The difference is that this --developer flag decides which weston.ini config file is used. By default we ship 2 different weston.ini files with our containers. You can see the two different files here: debian-docker-images/weston-dev.ini at bullseye · toradex/debian-docker-images · GitHub
But anyways in short this explains the different graphical output you are seeing in Weston. Your docker-compose files don’t have the --developer switch so they should be using the dark blue screen. At least this is what I get when I run your compose files, I haven’t gotten the gray screen so far, so not sure what’s going on there. Perhaps you had other containers running?
Best Regards,
Jeremias
I haven’t been able to replicate your issue so far on my setup using your image. Even when I try to reset the power during boot your UI container starts correctly every time.
The only thing I can suggest is to try and grab the logs when the issue occurs. sudo systemctl status docker-compose or sudo journalctl -f -u docker-compose will get the logs from the service that automatically starts your containers. Then maybe we can see what’s happening in the cases where it fails.
Since this seems to only happen sometimes I imagine there might be a race condition with your containers. Perhaps your UI application container is starting before the Weston container is ready.
If you see the example docker-compose file here: torizon-samples/docker-compose.arm64.yml at bullseye · toradex/torizon-samples · GitHub
There is the field depends_on which can help control the order your containers are started in.
Best Regards,
Jeremias
this is the difference:
- gray screen
docker-compose.service - Docker Compose service with docker compose
Loaded: loaded (/usr/lib/systemd/system/docker-compose.service; enabled; vendor preset: enabled)
Active: active (exited) since Thu 2021-11-04 13:26:41 UTC; 16min ago
Process: 978 ExecStart=/usr/bin/docker-compose -p torizon up -d --remove-orphans (code=exited, status=0/SUCCESS)
Process: 979 ExecStartPost=/usr/bin/rm -f /tmp/recovery-attempt.txt (code=exited, status=0/SUCCESS)
Main PID: 978 (code=exited, status=0/SUCCESS)
Nov 04 13:26:41 colibri-imx8x-06900156 systemd[1]: Starting Docker Compose service with docker compose…
Nov 04 13:26:41 colibri-imx8x-06900156 systemd[1]: Started Docker Compose service with docker compose.
Nov 04 13:26:45 colibri-imx8x-06900156 docker-compose[978]: Starting torizon_smartlogpro2_1 …
Nov 04 13:26:45 colibri-imx8x-06900156 docker-compose[978]: Starting torizon_weston_1 …
Nov 04 13:26:48 colibri-imx8x-06900156 docker-compose[978]: [108B blob data]
2.Dark blue screen:
docker-compose.service - Docker Compose service with docker compose
Loaded: loaded (/usr/lib/systemd/system/docker-compose.service; enabled; vendor preset: enabled)
Active: active (exited) since Thu 2021-11-04 13:47:13 UTC; 1min 3s ago
Process: 924 ExecStart=/usr/bin/docker-compose -p torizon up -d --remove-orphans (code=exited, status=0/SUCCESS)
Process: 925 ExecStartPost=/usr/bin/rm -f /tmp/recovery-attempt.txt (code=exited, status=0/SUCCESS)
Main PID: 924 (code=exited, status=0/SUCCESS)
Nov 04 13:47:13 colibri-imx8x-06900156 systemd[1]: Starting Docker Compose service with docker compose…
Nov 04 13:47:13 colibri-imx8x-06900156 systemd[1]: Started Docker Compose service with docker compose.
Nov 04 13:47:16 colibri-imx8x-06900156 docker-compose[924]: Creating network “torizon_default” with the default driver
Nov 04 13:47:17 colibri-imx8x-06900156 docker-compose[924]: Creating torizon_weston_1 …
Nov 04 13:47:17 colibri-imx8x-06900156 docker-compose[924]: Creating torizon_smartlogpro2_1 …
Nov 04 13:47:20 colibri-imx8x-06900156 docker-compose[924]: [108B blob data]
Yeah I think I see the issue here with those logs you provided.
In the gray screen case. The smartlogpro2_1 is started before the weston_1 container. While in the dark blue screen case it’s the opposite. I think my hunch was right about the race condition between the containers.
I’d suggest adding a dependency as I said in my previous comment to ensure the order the containers start in.
Best Regards,
Jeremias
/g/personal/serghey_savich_staticcontrol_com/EQkrMP6xYpRMtrXcx0xa9p0BvdODOXHD6_x9C4W760JSmQ?e=xfT7F6