Containers not running in TorizonCore with evaluation containers for iMX8M-Plus

vix · March 27, 2023, 1:25pm

I’ve just downloaded the last TorizonCore with evaluation containers image (build 220 for Verdin iMX8M-Plus) and installed using TEZI.
TorizonCore starts, and I can connect through ssh.
But I can’t see portainer page on HDMI monitor.
If I connect ssh and I run docker image ls I see

torizon@verdin-imx8mp-14777722:~$ docker image ls
REPOSITORY               TAG       IMAGE ID       CREATED                  SIZE
torizon/weston-vivante   3         779d54f7f4d1   Less than a second ago   510MB
portainer/portainer-ce   2.17.1    ada025d39772   Less than a second ago   267MB
torizon/chromium         2         cb7ac4913734   6 months ago             609MB

And docker container ls gives


torizon@verdin-imx8mp-14777722:~$ docker container ls
CONTAINER ID   IMAGE                    COMMAND                  CREATED         STATUS         PORTS
                                        NAMES
537452a778ee   portainer/portainer-ce   "/portainer --templa…"   6 minutes ago   Up 6 minutes   8000/tcp, 9443/tcp, 0.0.0.0:8840->9000/tcp, :::8840->9000/tcp   torizon-portainer-1

It seems that weston-vivante and chromium containers are not running as expected.

If I try the connection with ApolloX on WSL (I have version 0.0.67 and I think it’s the last one), the connection seems ok and I can see the logs of the containers
immagine
For chromium


 *  Executing task: docker logs --tail 1000 -f da5140c384d1ad9f6b64a527360e3bef158ae1446ed07501906f1981eaec043a 

[1:1:0223/003833.873126:ERROR:wayland_connection.cc(209)] Failed to connect to Wayland display
[1:1:0223/003833.873262:ERROR:ozone_platform_wayland.cc(226)] Failed to initialize Wayland platform
[1:1:0223/003833.873279:ERROR:env.cc(225)] The platform failed to initialize.  Exiting.

For weston-vivante

 *  Executing task: docker logs --tail 1000 -f 4f8c0eef313349fb069c92dbf3f8baa02a15fe46a71c540f245c22c2bfca98c6 

NXP EULA has already been accepted.
SoC is: 'i.MX8MP'
SoC has GPU: true
SoC has DPU: false
g2d implementation: viv
Couldn't open /dev/tty1
/usr/bin/entry.sh: line 86: [: =: unary operator expected
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: 2023-02-23 UTC
[00:38:32.159] weston 10.0.1
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: lf-5.15.52-2.1.0-10-g9452feba
[00:38:32.160] Command line: weston -Bdrm-backend.so --current-mode -Swayland-0
[00:38:32.160] OS: Linux, 5.15.77-6.2.0-devel+git.3f45ee6bd117, #1-TorizonCore SMP PREEMPT Thu Mar 23 13:16:48 UTC 2023, aarch64
[00:38:32.160] Flight recorder: enabled
[00:38:32.160] Using config file '/etc/xdg/weston/weston.ini'
[00:38:32.161] Output repaint window is 7 ms maximum.
[00:38:32.161] Loading module '/usr/lib/aarch64-linux-gnu/libweston-10/drm-backend.so'
[00:38:32.169] initializing drm backend
[00:38:32.169] Trying libseat launcher...
00:00:00.043 [INFO] [seatd/server.c:145] New client connected (pid: 27, uid: 1000, gid: 1000)
00:00:00.043 [INFO] [seatd/seat.c:170] Added client 1 to seat0
00:00:00.043 [ERROR] [common/terminal.c:162] Could not open target tty: Operation not permitted
00:00:00.043 [ERROR] [seatd/seat.c:72] Could not open terminal for VT 1: Operation not permitted
00:00:00.043 [ERROR] [seatd/seat.c:461] Could not open VT for client
00:00:00.043 [ERROR] [common/terminal.c:162] Could not open target tty: Operation not permitted
00:00:00.043 [ERROR] [seatd/seat.c:86] Could not open terminal to clean up VT 1: Operation not permitted
[00:38:32.170] libseat: session control granted
00:00:00.046 [ERROR] [seatd/seat.c:222] Could open device: client is not active
00:00:00.046 [ERROR] [seatd/client.c:238] Could not open device: Operation not permitted
00:00:00.047 [ERROR] [seatd/seat.c:222] Could open device: client is not active
00:00:00.047 [ERROR] [seatd/client.c:238] Could not open device: Operation not permitted
[00:38:32.176] no drm device found
00:00:00.050 [ERROR] [common/terminal.c:162] Could not open target tty: Operation not permitted
00:00:00.050 [ERROR] [seatd/seat.c:86] Could not open terminal to clean up VT 1: Operation not permitted
00:00:00.050 [INFO] [seatd/seat.c:524] Closed client 1 on seat0
00:00:00.050 [INFO] [seatd/seat.c:192] Removed client 1 from seat0
00:00:00.050 [INFO] [seatd/client.c:471] Client disconnected
[00:38:32.176] fatal: failed to create compositor backend
Internal warning: debug scope 'drm-backend' has not been destroyed.
00:00:00.054 [INFO] [seatd/seatd.c:218] seatd stopped
Switching back to vt 1

Is there something wrong?

EDIT: I can add that the Monthly TorizonCore with evaluation containers
6.2.0-devel-202303+build.6.container for iMX8M-Plus shows Portainer page on HDMI monitor.
And I can see the following images

torizon@verdin-imx8mp-14777722:~$ docker image ls
REPOSITORY               TAG       IMAGE ID       CREATED                  SIZE
portainer/portainer-ce   2.17.1    ada025d39772   Less than a second ago   267MB
torizon/chromium         2         cb7ac4913734   6 months ago             609MB
torizon/weston-vivante   2         eb17fa1e613f   6 months ago             424MB

I see that all the containers share the major tag 2.
Not sur eif mixing 2 and 3 like the lates noghtly builds is a good idea or not.

lucas_a.tx · March 27, 2023, 2:51pm

Hi @vix ,

For the next TorizonCore 6 releases we’re currently in the process of porting our Debian container images from Bullseye (tag 2) to Bookworm (tag 3). Given that our nightly builds are used for active development of new features and bug fixes, it’s expected that these type of releases will not be necessarily in a working state, as we don’t test them. You can see more details about our support strategy here: Embedded Linux Support Strategy | Toradex Developer Center

I see that all the containers share the major tag 2.
Not sur eif mixing 2 and 3 like the lates noghtly builds is a good idea or not.

The plan is to port all of our current Debian container images to tag 3 (Bookworm), but not all images are ported yet. I’d recommend using either our Monthly or Quarterly releases for the development of your project, always keeping in mind our support strategy for these kind of releases as well.

Best regards,
Lucas Akira

vix · March 27, 2023, 3:12pm

The problem is that I’m actively working with Toradex engineers to have new features implemented (basically Cortex-M firmware and 3D acceleration using GPU).
All these features are enabled in the nightlies and so I’m forced to follow them.
I know the bookworrm migration path, but for me it would be great if the migration can be finalized asap.

I cannot use the quarterly, I give a try to the monthly but I hope in the nightly…

lucas_a.tx · March 27, 2023, 9:45pm

Hi @vix ,

I know the bookworrm migration path, but for me it would be great if the migration can be finalized asap.

I understand your concern about the migration, but for the moment there isn’t too much that can be done in this regard other than to wait for the team here to finish their work. I’ll let the team know about your concern though.

Best regards,
Lucas Akira

vix · March 29, 2023, 10:26am

Hi @lucas_a.tx
thinking a little bit more on what happens, I think that there is another underlying issue:
the only container that has already been ported to bookworm is weston-vivante, and this is the container that fails.

*  Executing task: docker logs --tail 1000 -f 4f8c0eef313349fb069c92dbf3f8baa02a15fe46a71c540f245c22c2bfca98c6 

NXP EULA has already been accepted.
SoC is: 'i.MX8MP'
SoC has GPU: true
SoC has DPU: false
g2d implementation: viv
Couldn't open /dev/tty1
/usr/bin/entry.sh: line 86: [: =: unary operator expected
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: 2023-02-23 UTC
[00:38:32.159] weston 10.0.1
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: lf-5.15.52-2.1.0-10-g9452feba
[00:38:32.160] Command line: weston -Bdrm-backend.so --current-mode -Swayland-0
[00:38:32.160] OS: Linux, 5.15.77-6.2.0-devel+git.3f45ee6bd117, #1-TorizonCore SMP PREEMPT Thu Mar 23 13:16:48 UTC 2023, aarch64
[00:38:32.160] Flight recorder: enabled
[00:38:32.160] Using config file '/etc/xdg/weston/weston.ini'
[00:38:32.161] Output repaint window is 7 ms maximum.
[00:38:32.161] Loading module '/usr/lib/aarch64-linux-gnu/libweston-10/drm-backend.so'
[00:38:32.169] initializing drm backend
[00:38:32.169] Trying libseat launcher...
00:00:00.043 [INFO] [seatd/server.c:145] New client connected (pid: 27, uid: 1000, gid: 1000)
00:00:00.043 [INFO] [seatd/seat.c:170] Added client 1 to seat0
00:00:00.043 [ERROR] [common/terminal.c:162] Could not open target tty: Operation not permitted
00:00:00.043 [ERROR] [seatd/seat.c:72] Could not open terminal for VT 1: Operation not permitted
00:00:00.043 [ERROR] [seatd/seat.c:461] Could not open VT for client
00:00:00.043 [ERROR] [common/terminal.c:162] Could not open target tty: Operation not permitted
00:00:00.043 [ERROR] [seatd/seat.c:86] Could not open terminal to clean up VT 1: Operation not permitted
[00:38:32.170] libseat: session control granted
00:00:00.046 [ERROR] [seatd/seat.c:222] Could open device: client is not active
00:00:00.046 [ERROR] [seatd/client.c:238] Could not open device: Operation not permitted
00:00:00.047 [ERROR] [seatd/seat.c:222] Could open device: client is not active
00:00:00.047 [ERROR] [seatd/client.c:238] Could not open device: Operation not permitted
[00:38:32.176] no drm device found
00:00:00.050 [ERROR] [common/terminal.c:162] Could not open target tty: Operation not permitted
00:00:00.050 [ERROR] [seatd/seat.c:86] Could not open terminal to clean up VT 1: Operation not permitted
00:00:00.050 [INFO] [seatd/seat.c:524] Closed client 1 on seat0
00:00:00.050 [INFO] [seatd/seat.c:192] Removed client 1 from seat0
00:00:00.050 [INFO] [seatd/client.c:471] Client disconnected
[00:38:32.176] fatal: failed to create compositor backend
Internal warning: debug scope 'drm-backend' has not been destroyed.
00:00:00.054 [INFO] [seatd/seatd.c:218] seatd stopped
Switching back to vt 1

Chromium has not been ported yet, but it can’t run since it depends on weston-vivante.

The root error seems

Couldn't open /dev/tty1
...
00:00:00.043 [ERROR] [common/terminal.c:162] Could not open target tty: Operation not permitted

The question is: why the bookworm container weston-vivante fails on iMX8M-Plus?

lucas_a.tx · March 30, 2023, 8:52pm

Hi @vix ,

The question is: why the bookworm container weston-vivante fails on iMX8M-Plus?

I’ll pass this issue in particular to the TorizonCore team. For now the team is actively in the process of porting our Debian containers to Bookworm, which includes the ones you tested, so this problem will eventually be analyzed internally.

Keep an eye out at our News Announcement section for any updates on these containers.

Best regards,
Lucas Akira

leon.tx · March 31, 2023, 7:17pm

Hi @vix, I’m from the TorizonCore team.

why the bookworm container weston-vivante fails on iMX8M-Plus?

This is a known problem to us and the fix is at the end of our release pipeline, so it will be available shortly.

Best Regards,

rudhi.tx · June 14, 2023, 7:47am

Hello @vix ,

This issue has been fixed and the changes are included in the latest release of TorizonCore 6.2.0.
Debian Bookworm containers (including Weston) were published on Docker Hub with the major tag “3“ and are expected to work on all our SoMs supported by this release. Could you please give it a try and let us know how it goes?

vix · June 14, 2023, 8:08am

Hello @rudhi.tx
just to clarify, what do you mean “the latest release of 6.2.0”?
I always prefer to refer to a clear build
The Quarterly is 6.2.0 but it’s build 6.2.0-build2
I think you refer to either

monthly 6.3.0-devel-202306+build.8.container (released on 2023-06-09)

or

nightly 6.3.0-devel-20230613+build.299.container (released on 2023-06-13) or later

Can you confirm?

leon.tx · June 14, 2023, 12:43pm

Hi @vix

To clarify (as I wasn’t very clear when replying to Rudhi, apologies about that):
the issue is fixed in 6.2.0-build2. In that build CT_TAG_WESTON is kept at 2, meaning a bullseye release, as the bug was in Weston Bookworm (CT_TAG_WESTON=3).

All subsequent builds/releases (monthly 6.3.0-devel-202306+build.8.container, as you stated) include CT_TAG_WESTON=3 and thus the Bookworm version of Weston, including the fixes mentioned by Rudhi [1].

Please note we did not fully validate the Weston Bookworm container in the 6.2.0-build2, as it was schedule for the next release.

Regards,
Leon.

[1] for completeness, we refactored the way our Weston container starts, as the issue was related to wrong parsing in the command line options for seatd. Here’s the commit: weston: refactor the parsing for the command line options · toradex/torizon-containers@6c521fa · GitHub

rudhi.tx · July 10, 2023, 3:05pm

Hello @vix,

Do you have more open questions related to this topic? Have you been able to test the bookworm containers on TorizonCore 6 builds that @leon.tx listed above?

vix · July 11, 2023, 6:03am

Hello @rudhi.tx
I was almost ready to test it, but I had to upgrade to Windows 11 and now I’m blocked for this issue https://community.toradex.com/t/giving-internet-connection-to-the-verdin-som-through-ics-under-windows-11/19951.

I need a workaround for that…

SCordibella · July 12, 2023, 9:12am

Dear all, I think that the problem is event present with latest TorizonCore.
I download and install TorizonCore 6.3.0-devel-202306+build.8 on Apalis imx8 and I create a container based on weston-vivante version 3.
When I try to run my container I get the error:
/usr/bin/entry.sh: invalid option -- 'c'
If I run the weston-vivante this is the output:

Executing task: docker run --rm -it  torizon/weston-vivante:3 

SoC is: 'i.MX8QM'
SoC has GPU: true
SoC has DPU: true
g2d implementation: dpu
Couldn't open /dev/tty1

 *  The terminal process "/usr/bin/bash '-c', 'docker run --rm -it  torizon/weston-vivante:3'" terminated with exit code: 1.

Best regards,
Stefano.

jeremias.tx · July 12, 2023, 5:26pm

Hi @SCordibella,

You’re just simply running docker run --rm -it torizon/weston-vivante:3 ? In my case if I do this I get the following:

torizon@apalis-imx8-06738453:~$ docker run --rm -it  torizon/weston-vivante:3
SoC is: 'i.MX8QM'
SoC has GPU: true
SoC has DPU: true
g2d implementation: dpu
Couldn't open /dev/tty1

However, if I run command with all the flags as specified here: Debian Containers for Torizon | Toradex Developer Center

Then I get a working container launched:

torizon@apalis-imx8-06738453:~$ 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

This is all on the same version of TorizonCore as you specified:

torizon@apalis-imx8-06738453:~$ cat /etc/issue
TorizonCore 6.3.0-devel-202306+build.8 \n \l

Best Regards,
Jeremias

SCordibella · July 14, 2023, 9:46am

Hi @jeremias.tx , thank you for your help. I forgot to start the container in the right way because I run it from Visual Studio Code.

Now I follow the documentation, but I am unable to start the weston terminal example:

torizon@apalis-imx8-07107441:~$ docker run \
> -e ACCEPT_FSL_EULA=1 \
> -d --rm --name=wayland-app \
> -v /dev/dri:/dev/dri \
> -v /dev/galcore:/dev/galcore \
> -v /tmp:/tmp \
> --device-cgroup-rule='c 199:* rmw' \
> --device-cgroup-rule='c 226:* rmw' \
> torizon/weston-vivante:3 weston-terminal
95d039cfc870bb0a00098ea143bc98f49526d61c0f43000946b12d8bef9ee261
torizon@apalis-imx8-07107441:~$

The new container immediately stops and I don’t know how to debug or read the logs.

Am I missing something again?

Best regards,
Stefano.

SCordibella · July 14, 2023, 1:20pm

Update: if I add terminal parameter to the previous command:

docker run -e ACCEPT_FSL_EULA=1 -ti --rm --name=wayland-app \
--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' \
--privileged torizon/weston-vivante:3 weston-terminal --developer --tty=/dev/tty7

I have the following result:

SoC is: 'i.MX8QM'
SoC has GPU: true
SoC has DPU: true
g2d implementation: dpu
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  [seatd/seat.c:39] Created VT-bound seat seat0
00:00:00.000  [seatd/seatd.c:194] seatd started
Date: 2023-07-14 UTC
[13:19:08.289] weston 10.0.1
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: lf-5.15.52-2.1.0-10-g9452feba
[13:19:08.290] Command line: weston -Bdrm-backend.so --current-mode -Swayland-0 weston-terminal
[13:19:08.290] OS: Linux, 5.15.77-6.2.0+git.aa0ff7e3554e, #1-TorizonCore SMP PREEMPT Wed Mar 29 15:33:40 UTC 2023, aarch64
[13:19:08.290] Flight recorder: enabled
[13:19:08.290] Using config file '/etc/xdg/weston-dev/weston.ini'
[13:19:08.291] Output repaint window is 7 ms maximum.
[13:19:08.291] Loading module '/usr/lib/aarch64-linux-gnu/libweston-10/drm-backend.so'
[13:19:08.302] initializing drm backend
[13:19:08.302] Trying libseat launcher...
00:00:00.066  [seatd/server.c:145] New client connected (pid: 27, uid: 1000, gid: 1000)
00:00:00.067  [seatd/seat.c:170] Added client 7 to seat0
00:00:00.067  [seatd/seat.c:480] Opened client 7 on seat0
[13:19:08.304] libseat: session control granted
00:00:00.071  [seatd/seat.c:281] Could not make device fd drm master: Device or resource busy
[13:19:08.309] using /dev/dri/card1
[13:19:08.309] DRM: supports atomic modesetting
[13:19:08.309] DRM: supports GBM modifiers
[13:19:08.309] DRM: supports picture aspect ratio
[13:19:08.309] Loading module '/usr/lib/aarch64-linux-gnu/libweston-10/gl-renderer.so'
[13:19:08.322] EGL client extensions: EGL_EXT_client_extensions
               EGL_EXT_platform_base EGL_KHR_platform_wayland
               EGL_EXT_platform_wayland EGL_EXT_device_query
               EGL_EXT_device_drm EGL_EXT_device_drm_render_node
               EGL_KHR_platform_gbm
[13:19:08.325] EGL device extensions: EGL_EXT_client_extensions
               EGL_EXT_platform_base EGL_KHR_platform_wayland
               EGL_EXT_platform_wayland EGL_EXT_device_query
               EGL_EXT_device_drm EGL_EXT_device_drm_render_node
               EGL_KHR_platform_gbm
[13:19:08.326] EGL version: 1.5
[13:19:08.326] EGL vendor: Vivante Corporation
[13:19:08.326] EGL client APIs: OpenGL_ES OpenVG
[13:19:08.326] EGL extensions: EGL_KHR_fence_sync EGL_KHR_reusable_sync
               EGL_KHR_wait_sync EGL_KHR_image EGL_KHR_image_base
               EGL_KHR_image_pixmap EGL_KHR_gl_texture_2D_image
               EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image
               EGL_EXT_image_dma_buf_import
               EGL_EXT_image_dma_buf_import_modifiers EGL_KHR_lock_surface
               EGL_KHR_create_context EGL_KHR_no_config_context
               EGL_KHR_surfaceless_context EGL_KHR_get_all_proc_addresses
               EGL_EXT_buffer_age EGL_ANDROID_native_fence_sync
               EGL_WL_bind_wayland_display
               EGL_WL_create_wayland_buffer_from_image EGL_KHR_partial_update
               EGL_EXT_swap_buffers_with_damage
               EGL_KHR_swap_buffers_with_damage EGL_EXT_pixel_format_float
[13:19:08.326] EGL_KHR_surfaceless_context available
00:00:00.156  [seatd/client.c:471] Client disconnected
00:00:00.157  [seatd/seat.c:332] Could not revoke drm master on device fd: Invalid argument
00:00:00.157  [seatd/seat.c:418] No clients on seat0 to activate
00:00:00.157  [seatd/seat.c:524] Closed client 7 on seat0
00:00:00.157  [seatd/seat.c:192] Removed client 7 from seat0
00:00:00.167  [seatd/seatd.c:218] seatd stopped
Switching back to vt 7

But nothing appear on the screen…

jeremias.tx · July 14, 2023, 6:50pm

So for clarity to bring up the weston-terminal utility like this you need 2 containers running side by side. You need the initial container, to run the overall Weston/Wayland process this is using the same command as shown before.

Then you need a second container to start weston-terminal on top of the Weston/Wayland process of the 1st container. The 2nd container should have a command like so:

docker run -e ACCEPT_FSL_EULA=1 --rm -d --name=wayland-app  -v /dev/dri:/dev/dri -v /dev/galcore:/dev/galcore -v /tmp:/tmp --device-cgroup-rule='c 199:* rmw' --device-cgroup-rule='c 226:* rmw' --entrypoint weston-terminal torizon/weston-vivante:$CT_TAG_WESTON_VIVANTE

I see the documentation has a slightly different possibly outdated command I will look into this and report to our team.

In theory you could have this all in one container but this would require you start Weston/Wayland process with 1 container then you’d have to get a shell into that container to then manually start weston-terminal.

Best Regards,
Jeremias

SCordibella · August 11, 2023, 2:20pm

Hi @jeremias.tx finally I managed to run two containers and I am also able to run containers with GUI (the python-qt5 sample).

Then I move to a pure python GUI that I run with:

docker run \
-e ACCEPT_FSL_EULA=1 \
-e DISPLAY=wayland-0 \
-e WAYLAND_DISPLAY=wayland-0 \
-e XDG_RUNTIME_DIR=/tmp \
-d --rm --name=pythongui-app \
-p 8080:8080/tcp \
-v /dev/dri:/dev/dri \
-v /dev/galcore:/dev/galcore \
-v /tmp/wayland-0:/tmp/wayland-0 \
--device-cgroup-rule='c 199:* rmw' \
--device-cgroup-rule='c 226:* rmw' \
pythongui:latest

But unfortunately it seems that the “DISPLAY” variable is not resolved, I made many tests changing the DISPLAY values: adding the :0 or the :0, but nothing changes.
Here is the error:

[2023-08-11 09:23:03,143] ERROR in app: Exception on /1/print-files/radio/start [POST]
Traceback (most recent call last):
  File "/home/torizon/.venv/lib/python3.11/site-packages/flask/app.py", line 2073, in wsgi_app
    response = self.full_dispatch_request()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/torizon/.venv/lib/python3.11/site-packages/flask/app.py", line 1519, in full_dispatch_request
    rv = self.handle_user_exception(e)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/torizon/.venv/lib/python3.11/site-packages/flask/app.py", line 1517, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/torizon/.venv/lib/python3.11/site-packages/flask/app.py", line 1503, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**req.view_args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/torizon/.venv/lib/python3.11/site-packages/asgiref/sync.py", line 218, in __call__
    return call_result.result()
           ^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/concurrent/futures/_base.py", line 449, in result
    return self.__get_result()
           ^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/concurrent/futures/_base.py", line 401, in __get_result
    raise self._exception
  File "/home/torizon/.venv/lib/python3.11/site-packages/asgiref/sync.py", line 284, in main_wrap
    result = await self.awaitable(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/torizon/.venv/lib/python3.11/site-packages/connexion/decorators/decorator.py", line 55, in wrapper
    connexion_response = await connexion_response
                         ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/torizon/server/controllers/default_controller.py", line 189, in start_print
    display.run()
  File "/home/torizon/server/backend/display.py", line 17, in run
    self.root = Tk()
                ^^^^
  File "/usr/lib/python3.11/tkinter/__init__.py", line 2326, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
_tkinter.TclError: couldn't connect to display "wayland-0"

Is this error related to Python code or it depends by a container configuration?

Best regards,
Stefano.

leon.tx · August 11, 2023, 4:04pm

@SCordibella

I see you’re mounting -v /tmp/wayland-0:/tmp/wayland-0, but I believe the socket is created at /tmp/1000-runtime-dir. -v has this footgun in which, if you mount a file/directory that doesn’t exist, it will happily create that file/directory inside the container.

Incidentally, I have a small sample that I just pushed to GitHub that also uses tk (although with pysimplegui) and it works nicely: GitHub - leonheldattoradex/pysimplegui. In this example I just mount the whole /tmp volume.

SCordibella · August 30, 2023, 8:43am

Hi @leon.tx I try to run your pysimplegui using the command docker-compose up from the board, but I have the following error:

> Attaching to pysimplegui-pysimplegui-1, pysimplegui-weston-1
> pysimplegui-weston-1       | Switching VT tty1 to text mode if currently in graphics mode
> pysimplegui-weston-1       | Couldn't open /dev/tty1
> pysimplegui-weston-1 exited with code 1
> pysimplegui-pysimplegui-1  | Traceback (most recent call last):
> pysimplegui-pysimplegui-1  |   File "/home/torizon/pysimplegui-example.py", line 3, in <module>
> pysimplegui-pysimplegui-1  |     sg.Window(title="Hello World", layout=[[]], margins=(100, 50)).read()
> pysimplegui-pysimplegui-1  |   File "/usr/local/lib/python3.11/dist-packages/PySimpleGUI/PySimpleGUI.py", line 10079, in read
> pysimplegui-pysimplegui-1  |     results = self._read(timeout=timeout, timeout_key=timeout_key)
> pysimplegui-pysimplegui-1  |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> pysimplegui-pysimplegui-1  |   File "/usr/local/lib/python3.11/dist-packages/PySimpleGUI/PySimpleGUI.py", line 10150, in _read
> pysimplegui-pysimplegui-1  |     self._Show()
> pysimplegui-pysimplegui-1  |   File "/usr/local/lib/python3.11/dist-packages/PySimpleGUI/PySimpleGUI.py", line 9890, in _Show
> pysimplegui-pysimplegui-1  |     StartupTK(self)
> pysimplegui-pysimplegui-1  |   File "/usr/local/lib/python3.11/dist-packages/PySimpleGUI/PySimpleGUI.py", line 16821, in StartupTK
> pysimplegui-pysimplegui-1  |     _get_hidden_master_root()
> pysimplegui-pysimplegui-1  |   File "/usr/local/lib/python3.11/dist-packages/PySimpleGUI/PySimpleGUI.py", line 16708, in _get_hidden_master_root
> pysimplegui-pysimplegui-1  |     Window.hidden_master_root = tk.Tk()
> pysimplegui-pysimplegui-1  |                                 ^^^^^^^
> pysimplegui-pysimplegui-1  |   File "/usr/lib/python3.11/tkinter/__init__.py", line 2326, in __init__
> pysimplegui-pysimplegui-1  |     self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
> pysimplegui-pysimplegui-1  |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> pysimplegui-pysimplegui-1  | _tkinter.TclError: couldn't connect to display ":0"
> pysimplegui-pysimplegui-1 exited with code 1

It looks the same that I have running my code. Could you please share the environment that you set to run the pysimplegui?

Best regards,
Stefano.