Hi,
After the upgrade of the extensions, the (community) template for Avalonia GTK MVVM is not working any more out of the box. We use a Colibri IMX8 on an IRIS evaluation board.
During the start of the default template, there is an exception:
"System.Exception" occured in Avalonia.X11.dll with .: 'XOpenDisplay failed'
It seems the root cause is that a different image is used in docker-compose.yml
weston:
image: torizon/weston${GPU}:3
Previously it was
weston:
image: torizonextras/weston${GPU}:2
I will add more details if I find information. Maybe someone else already ran into this problem and found a better fix than reverting to a different image.
Best regards,
Markus
Hi @KidIcarus ,
Thanks for reporting this.
Does it work again, if you roll back to the previous version?
Best Regards
Kevin
Hi @kevin.tx
it does work in a previous version - mainly because then the used template refers to a different container image:
torizonextras/weston:2
instead of
torizon/weston:3
in the newer plugin version. What is strange is that it seems to generate different “docker-compose.yml” files regardless of the plugion version. I have two notebooks, both have the 2.0.0 Toradex extension. One runs Windows 10 + WSL, the other directly with Ubuntu.
On the Ubuntu machine the template for Avalonia GTK MVVM is using “torizonextras/weston2” bot on window the template creates the docker-compose.yml file with “torizon/weston3” which causes the problem. If I change to torizon/weston3 manually, the issue occurs. The fix is to use torionextras/weston2.
Are the templates somehow dynamically updated/loaded or do they come packed with the extension?
Best regards,
Markus
Hi @KidIcarus
yes, templates are synced at runtime during extension initialization. They come from the following repository: GitHub - toradex/vscode-torizon-templates: VS Code Torizon Integrated Development Environment Templates
You may notice that there are three branches:
dev: development branch;bookworm: uses the new images based on the testing release of Debian;bullseye: uses images based on the stable release of Debian;
As in TorizonCore 6 we need some libraries that are only available in bookworm images, today by default the extension syncs with bookworm.
But if this is causing problems for you, I recommend using the following configuration in your settings.json global:
"apollox.templatesBranch": "bullseye",
Open and close the VS Code window and this should sync.
Remembering that Avalonia templates are community-maintained templates and are not yet in our QA pipeline. If this is critical for your business, I recommend mention this to your sales representative so that our Product Manager can track the interest in this framework and we can promote it to Toradex supported.
Hi @matheus.tx
Thank you for the information. I tried a little meanwhile and did a reinstallation of the plugin (including deleting all associated folders) now the Linux notebook uses the “torizon/weston{GPU}:3” entry as well. Luckily, this now also works on my Pi with an external HDMI display. Maybe because the PI is already running version 6.0.0 whereas the IMX8 board is still on 5.7.2.
I will test this once more in the office with an IMX8 on an IRIS board.
I can forward the info regarding the Avalonia templates. We are planning to use that as our main development framework for our upcoming products.
We do have some other issues with the extension itself but need to figure out first what is caused by our network and what could be related to external factors. For example, if my IP changes, the connected IMX8 is not updated and the insecure registry entry in the docker daemon.json still keeps the old IP.
But since we get a lot of fast feedback here, we are in good hands 
Best regards
Markus
1 Like
hmm, this is bad. I will open a ticket about this on our board. Thanks for mentioning.
Best Regards,
Hi @matheus.tx
Thank you and maybe you can also check how we can fix the initial issue. We tried again with the IMX8 board running a TorizonCore version 6 and the Weston:3 template. The exception that no display has been found persists. I am not sure what caused the issue, I just wonder why the SoM does not have a GPU. The test was done with a IRIS evaluation board and the 7" capacitive demo display.
Best regards,
Markus
A more detailed log of the error:
torizon@colibri-imx8x:~$ TAG=arm64 GPU=-vivante docker-compose run weston
WARNING: The LOCAL_REGISTRY variable is not set. Defaulting to a blank string.
WARNING: The DOCKER_LOGIN variable is not set. Defaulting to a blank string.
Creating torizon_weston_run ... done
SoC is: 'i.MX8QXP'
SoC has GPU: false
SoC has DPU: false
g2d implementation: viv
Fallbacking to software renderer.
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-04-20 UTC
[15:10:06.313] 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
[15:10:06.313] Command line: weston -Bdrm-backend.so --current-mode -Swayland-0 --use-pixman
[15:10:06.313] OS: Linux, 5.4.193-5.7.0-devel+git.90bfeac00dbe, #1-TorizonCore SMP PREEMPT Tue May 24 09:56:51 UTC 2022, aarch64
[15:10:06.313] Flight recorder: enabled
[15:10:06.314] Using config file '/etc/xdg/weston/weston.ini'
[15:10:06.315] Output repaint window is 7 ms maximum.
[15:10:06.315] Loading module '/usr/lib/aarch64-linux-gnu/libweston-10/drm-backend.so'
[15:10:06.329] initializing drm backend
[15:10:06.329] Trying libseat launcher...
00:00:00.068 [seatd/server.c:145] New client connected (pid: 23, uid: 1000, gid: 1000)
00:00:00.069 [seatd/seat.c:170] Added client 1 to seat0
00:00:00.069 [seatd/seat.c:480] Opened client 1 on seat0
[15:10:06.331] libseat: session control granted
[15:10:06.333] no drm device found
00:00:00.072 [seatd/seat.c:418] No clients on seat0 to activate
00:00:00.072 [seatd/seat.c:524] Closed client 1 on seat0
00:00:00.072 [seatd/seat.c:192] Removed client 1 from seat0
00:00:00.072 [seatd/client.c:471] Client disconnected
[15:10:06.334] fatal: failed to create compositor backend
Internal warning: debug scope 'drm-backend' has not been destroyed.
00:00:00.078 [seatd/seatd.c:218] seatd stopped
Switching back to vt 1
ERROR: 1
Hello @KidIcarus ,
This issue should have been fixed in the version 2.1.0
Best regards,
Josep
1 Like
