iMX6ULL GUI Application

Dear Sirs,

I need to develop a GUI application for a TIPRO BF03 device equipped with a Toradex Colibri iMX6ULL with 1GB of RAM, 4GB eMMC and a 3.5" touchscreen PCAP.

For this application, I would like to reuse some of the code from another .Net Core 3.1 application.
Following your guides I created a test “Hello world” application with .NET 8.0 and Avalonia framework for the GUI, but I found that the application is very slow and not very responsive.

In your opinion, is it possible to develop a fast and responsive GUI application with .NET for this hardware?
In this case, are there any libraries to interact with the hardware (keyboard, speaker, microphone) of this device?

If not, which language and framework do you recommend me to use?

Thank you


Bootloader: U-Boot
Kernel version: 6.1.22-6.2.0+git.3b29299e5f60 #1-TorizonCore Wed Jan 25 12:09:15 UTC 2023
Distro name: NAME=“TorizonCore Upstream”
Distro version: VERSION_ID=6.2.0-build.2
Hardware info

HW model: Toradex Colibri iMX6ULL 1GB (eMMC) on Colibri Evaluation Board V3
Toradex version: 0062 V1.1A
Processor arch: armv7l

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello,

Developing a fast and responsive GUI application on the Toradex Colibri iMX6ULL using .NET and Avalonia can be challenging due to the resource constraints of the hardware and the overhead introduced by running .NET applications. The iMX6ULL, while capable for many embedded applications, may not provide the best performance for .NET applications that require a significant amount of resources, especially when using frameworks not optimized for such embedded environments.

For applications requiring interaction with hardware components like keyboards, speakers, and microphones, you would typically use platform-specific libraries or interfaces provided by the Linux system. However, .NET’s support for direct hardware interaction in embedded environments can be limited, and you might need to implement native interop or use specific libraries designed for such purposes, which might not be readily available or well-documented for all hardware components.

Given the performance issues you’ve encountered with .NET and Avalonia, I recommend considering alternatives that are more suited to the capabilities of the iMX6ULL and the embedded Linux environment provided by Torizon. Qt with C++ is a highly recommended choice for developing GUI applications on Toradex devices. Qt is well-supported on Torizon and offers a good balance between performance and ease of development. It provides direct access to hardware acceleration features, which can significantly improve the responsiveness and fluidity of your GUI. Additionally, Qt offers extensive documentation and a wide range of libraries for interacting with various hardware components.

For a more lightweight approach, you might also consider using frameworks like LVGL (Light and Versatile Graphics Library), which is designed for use on embedded systems with limited resources. LVGL can be used with C or C++ and provides tools for creating modern, attractive interfaces without the overhead of more complex frameworks.

In summary, while it is possible to develop GUI applications with .NET for the Colibri iMX6ULL, the performance may not meet your expectations due to the hardware’s limitations and the overhead of the .NET runtime. Exploring alternatives like Qt or LVGL with C/C++ might offer a better path forward for achieving a fast and responsive GUI application on this hardware platform.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

High performance, low power Embedded Computing Systems | Toradex Developer Center.

Hey @Filippo-GEG

could you please tell me which kind of template you used? We have two for Avalonia, using framebuffer and another one that uses GTK.

Hi @matheus.tx

Thank you for the answer!

I tried both templates, but only with the GTK Template, I was able to compile and run it on the iMX6ULL.
As I was saying however, the GUI, despite only having a form and a button, was very very slow.
Response times when moving the window or pressing the button were very long.

I was trying Qt and Slint templates for testing purposes.
I followed your Youtube videos and tried to compile an empty project (Hello Torizon), but I always get an error from Remote debug and the container is terminated.
(Starting: “ssh” -T -q -p 2231 -i /home/torizon/QtTest/.conf/id_rsa -o StrictHostKeyChecking=no -o “UserKnownHostsFile /dev/null” torizon@195.1.1.160 “/usr/bin /gdb --interpreter=mi”
“ssh” exited with code 255 (0xFF).)

I need to create a GUI application that makes a socket connection (TCP/UDP) towards a radio infrastructure and allows me to manage voice communications with radio devices via the microphone and speaker of the device that mounts the iMX6ULL.

I have already developed an application of this type for PC Desktop in C# and .Net Core 3.1 and, if it were possible, I would like to reuse the code already written.
However, if .Net is too heavy, I can evaluate/learn other languages ​​and frameworks.
However, Qt seems to me to have high licensing costs for commercial applications; is it correct?

I saw that Mono and GTK# can also be used; what do you think?
Which framework/language do you recommend using for a fast and responsive GUI application that should be used in Emergency Operations Centers for our SoM?

Thank you and have a nice day
Filippo

Hi @Filippo-GEG and @matheus.tx

I’ve made a post on Avalonia GTK MVVM that I run on the following configuration:

torizon@verdin-imx8mp-15229850:~$ sudo tdx-info
Password:

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           5.15.148-6.6.1+git.23a8e831749d #1-TorizonCore SMP PREEMPT Thu Feb 29 20:25:21 UTC 2024
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/f5f0b9e40c1595ab904ce493a792a0b54e17f0dc3ce6832ddb889452bdd13704/0
Distro name:              NAME="TorizonCore"
Distro version:           VERSION_ID=6.6.1-build.14
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-imx8mp-15229850
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version:          0058 V1.1B
Serial number:            15229850
Processor arch:           aarch64
------------------------------------------------------------

Here is my evaluation kit version:

[Hardware Configuration]
Verdin iMX8M Plus Evaluation Kit with Touchscreen
with:
SOM i.MX8M Plus Quad 4GB WB IT v1.1B
Dahlia Carrier Board v1.1D
Verdin DSI to LVDS rev 1.1A
Capacitive Touch Display 10.1" v1.0A

Have a look to this post and to my public GitHub repo, and make a try with your configuration.

This is a good sample to see is you can achieve sufficient UX performances on your device for you App.

Sincerely,
François.

1 Like

@flepron ,

I tried to to clone your AvaloniaUITheSeriesGTKMVVM, I executed the nuget procedure but on “dotnet restore” command I get the “error NU1101: Unable to find package CommunityToolkit.Labs.Extensions.DependencyInjection. No packages exist with this id in source(s)” error; so I can’t test it.

@matheus.tx
I solved the “Starting ssh…” error; it seems another container used debugger port.
Do you have any advice for me regarding the above?

Thank you in advance,
Best regards
Filippo

@Filippo-GEG

if you are trying different projects to evaluate them , make sure to go to the Docker activity panel and Docker compose down or Remove all the previously created containers:

image

About the Avalonia performance on iMX6ull: the Avalonia does not support Wayland and the official Toradex Containers and packaging team only supports Weston. So, behind the scenes Avalonia runs using Xwayland, and is know that the performance is very poor. Options you have:

  1. Use the experimental branch of the templates which, instead of Weston, uses the Xfce desktop environment for create a new .NET 8 C# Avalonia GTK MVVM project; Check here how to change the templates branch. But instead dev you will use next:
        "torizon.templatesBranch": "next",
        "torizon.templatesTag": "next"

This should have a better performance than using Weston.

  1. Use the framebuffer device directly. Using the template .NET 8 C# Avalonia Frame Buffer:

image

Since Avalonia templates are community developed also using the next branch of templates, as I tell you to use above, for create the .NET 8 C# Avalonia Frame Buffer should be good, there are some fixes there that are not in the stable yet.
Using directly the /dev/fb0 should also have a better performance.

Let me know if you try any of these methods, feedback about your development experience is greatly appreciated.

@flepron this sounds interesting, I will try to test on my dev environment.

1 Like

Hi @matheus.tx

Thanks for the answer.

Now I have a problem with my iMX6ULL; while I was trying to compile and deploy the @flepron project, the module started restarting continuously.
I think it’s a Docker problem; in fact, if during startup I quickly log into ssh and send the command “sudo systemctl stop docker”, the module stops restarting continuously, but obviously, I can no longer access the SoM with VSCode.

I already tried to rename docker and containerd folders and docker compose file to avoid container execution at startup, but keep restarting continuosly.

Do you have any ideas on how to reset Docker?

Unfortunately I don’t have the image of the Operating System of the iMX6ULL module and I don’t know how to restore it, because the module is inside a Console and the Operating System was created by the console supplier.

Anyway…
I understand that Avalonia and/or .NET 8.0 are too heavy for our module anyway.
However, I will try what you suggested as soon as I manage to restore the module.
So…Which framework/language do you recommend using for a fast and responsive GUI application on our SoM?

Thank you in advance
Best regards,
Filippo

@Filippo-GEG

the @flepron project is using the old templates, based on Weston Xwayland, so should not be the best fit for imx6ull. Please follow the instructions that I described to you to create a project, so then you can copy the source code files (C# and .axaml) from the @flepron project to try.

About the restart, could you try to check the content of the file /etc/docker/daemon.json and share with me?

Best Regards,

Hi @matheus.tx

Thank you for support.

The content of /etc/docker/daemon.json is:

{
   "insecure-registries" : [":5002"]
}

Since the device was no longer usable, we used a second device.

We only changed the IP address from DHCP to Static.

As soon as we just tried to connect to the device (without performing any compilation) with VSCode, the VSCode connection failed and this second device also started to restart continuously.

This is very strange…it seems that starting the Docker service causes the device to crash and reboot.

I will try the instructions you gave me as soon as I have the module working again, it is in my interest to be able to reuse the C# code.
But can you please tell me what, in your opinion, are the best framework and language for developing a fast and high-performance GUI application while avoiding large licensing costs?
Could it be C++ and GTK3?

Thank you again for your time matheus
Best regards,
Filippo

@Filippo-GEG

yeah, for some reason the host IP is not set :pensive:, so this is a invalid daemon.json, what is the cause of the rebooting. I will check here how to fix this ASAP, or at least prevent this behavior in case there is no Host IP reported.

Could you also share with me the version of VS Code, the version of the Torizon IDE extension and if you are using Windows or Linux on your dev environment?

Thanks in advance.

@Filippo-GEG

the issue with the empty Host IP should be fixed on v2.5.175 of the Torizon IDE Extension - Visual Studio Marketplace. This is a pre-release version, so you have to install it using the Install Pre-Release button.

Hi @matheus.tx

Thank you for the new extension, but I can’t understand… I had set a static IP for the module.
My device now, keeps rebooting regardless of me trying to connect with VSCode.
How can the new VSCode extension solve the problem of my 2 devices constantly rebooting?

Can you please answer me about the best framework/language for iMX6ULL?

Thank you
Best regards,
Filippo

@Filippo-GEG

oh yes, the fix on the extension side was to prevent the behavior, but if the device is already in the rebooting state you can try to remove the /etc/docker/daemon.json, then the next reboot or Docker restart this should work fine.

As you said that would like to reuse previous C# code, Avalonia should be a good alternative. The imx6ull does not have GPU, so don’t expect to use very advanced features, but for a basic UI it should work well.

Try the new templates from next and let me know about the performance. From my tests looks fine.

Best Regards,

Hi @Filippo-GEG and @matheus.tx

Sorry for my late answer.

@Filippo-GEG, did you make sure that you’ve added the Nuget Source repository as described in the readme.md file:

#update package list
sudo apt-get update && sudo apt-get install

#process this command if nuget utility is not yet installed
sudo apt-get install nuget

#add Nuget source https://pkgs.dev.azure.com/dotnet/CommunityToolkit/_packaging/CommunityToolkit-Labs/nuget/v3/index.json
nuget sources Add -Name "CommunityToolkit-Labs" -Source "https://pkgs.dev.azure.com/dotnet/CommunityToolkit/_packaging/CommunityToolkit-Labs/nuget/v3/index.json"

#verify it has been added the the Nuget source repositoris (by default, https://www.nuget.org/api/v2/ is always there)
nuget sources list
Registered Sources:

  1.  https://www.nuget.org/api/v2/ [Enabled]
      https://www.nuget.org/api/v2/
  2.  CommunityToolkit-Labs [Enabled]
      https://pkgs.dev.azure.com/dotnet/CommunityToolkit/_packaging/CommunityToolkit-Labs/nuget/v3/index.json

because the package CommunityToolkit.Labs.Extensions.DependencyInjection can only be found in the Nuget Repo : https://pkgs.dev.azure.com/dotnet/CommunityToolkit/_packaging/CommunityToolkit-Labs/nuget/v3/index.json.

Please let me know if this works.

I have created a clone of the repo FLepron-PoolCop/AvaloniaUITheSeriesGTKMVVM (github.com) which uses the GTK MVVM template of @matheus.tx , but using this time the Avalonia FB DRM template.

The repo is avialable here: FLepron-PoolCop/AvaloniaUITheSeriesFBDRM (github.com).

This should be faster using the FB or DRM.

This version works properly on my setup described in my previous post.

Let me know if you need further help.

Sincerely,
François.

Hi @matheus.tx,

By renaming the daemon.json file, both devices now boot correctly…thank you very much!

Now I’m trying Avalonia…
I updated the VSCode Torizon extension (2.5.175) and created a new Avalonia Frame Buffer DRM project by setting next the template branch.

I still have to study the Avalonia framework, so I simply replaced the Welcome to Avalonia text with a button.

The application compiles and runs correctly on the iMX6ULL but the displayed window has no title bar and therefore I cannot test responsiveness.
I think this is because the Torizon extension creates a UserControl instead of a Window.
I then tested the responsiveness of the button and it seems good.

However, I noticed that the mouse pointer is not visible on the display and in the VSCode Debug Console, I find the following messages:

[LinuxFramebuffer/Input/LibInput/Pointer] The pointer event LIBINPUT_EVENT_POINTER_MOTION is not mapped. (LibInputBackend #64923656)
libinput error: event1 - Logitech USB Optical Mouse: client bug: event processing lagging behind by 27ms, **your system is too slow**.

Now I continue testing, just wanted to give you some feedback and thank you for your work.

If possible, I wanted to ask you something else…
I modified the Torizon VsCode project’s docker-compose.yml file to include Portainer, but when I start Debugging, only the Avalonia container is deployed on the device.
Is Docker compose not used during debugging?

Thank you and have a nice day

Best regards,
Filippo

Hi @Filippo-GEG

docker-compose.yml is used for debug as well as for release mode.

I give you the docker-compose.yml file of my repo : GitHub - FLepron-PoolCop/AvaloniaUITheSeriesFBDRM which uses FB.

You can see that you have two configurations in the same file:

  • one for debug : avalonia-ui-the-series-fb-drm-debug
  • another one for release : avalonia-ui-the-series-fb-drm

This is the same story for Dockerfile.debug and Dockerfile.

As you know, the docker-compose.yml file specify the resources you want to access to (device_cgroup_rules) and volumes binding.

version: "3.9"
services:
  avalonia-ui-the-series-fb-drm-debug:
    build:
        context: .
        dockerfile: Dockerfile.debug
    image: ${LOCAL_REGISTRY}:5002/avalonia-ui-the-series-fb-drm:${TAG}
    # Required to get udev events from host udevd via netlink
    network_mode: host
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /dev
        target: /dev
      - type: bind
        source: /run/udev
        target: /run/udev
    cap_add:
      - CAP_SYS_TTY_CONFIG
    # Add device access rights through cgroup...
    device_cgroup_rules:
      # ... for tty0
      - "c 4:0 rmw"
      # ... for tty7
      - "c 4:7 rmw"
      # ... for /dev/input devices
      - "c 13:* rmw"
      # ... for /dev/dri devices
      - "c 226:* rmw"
      - "c 199:* rmw"
      # ... for /dev/fb0
      - "c 29:* rmw"

  avalonia-ui-the-series-fb-drm:
    build:
        context: .
        dockerfile: Dockerfile
    image: ${DOCKER_LOGIN}/avalonia-ui-the-series-fb-drm:${TAG}
    # Required to get udev events from host udevd via netlink
    network_mode: host
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /dev
        target: /dev
      - type: bind
        source: /run/udev
        target: /run/udev
    cap_add:
      - CAP_SYS_TTY_CONFIG
    # Add device access rights through cgroup...
    device_cgroup_rules:
      # ... for tty0
      - "c 4:0 rmw"
      # ... for tty7
      - "c 4:7 rmw"
      # ... for /dev/input devices
      - "c 13:* rmw"
      # ... for /dev/dri devices
      - "c 226:* rmw"
      - "c 199:* rmw"
      # ... for /dev/fb0
      - "c 29:* rmw"

Have a look to linux/Documentation/admin-guide/devices.txt at master · torvalds/linux (github.com) to understand the device identifiers.

Just for information, In FB DRM, the mouse pointer is not visible on my side, while it is visible and operational in GTK MVVM.

It can work, but honestly I have not dug deeper since I have a touchscreen.

Process the command sudo tdx-info -d to see the device available on your board and thier identifiers.

In my case I have the following ones:

torizon@verdin-imx8mp-15229850:~$ sudo tdx-info -d
Password: 

Devices
------------------------------------------------------------
All devices available:
                          total 0
                          crw-r--r-- 1 root root     10, 235 Jul 19 06:11 autofs
                          drwxr-xr-x 2 root root         620 Jul 19 13:36 block
                          crw------- 1 root root     10, 234 Jul 19 06:11 btrfs-control
                          drwxr-xr-x 3 root root          60 Jul 19 06:11 bus
                          crw------- 1 root root     10, 126 Jul 19 06:11 caam-keygen
                          drwxr-xr-x 2 root root        4.0K Jul 19 12:57 char
                          crw------- 1 root root      5,   1 Jul 19 06:11 console
                          crw------- 1 root root     10, 125 Jul 19 06:11 cpu_dma_latency
                          crw------- 1 root root     10, 203 Jul 19 06:11 cuse
                          drwxr-xr-x 7 root root         140 Jul 19 06:11 disk
                          drwxr-xr-x 2 root root         100 Jan  1  1970 dma_heap
                          drwxr-xr-x 3 root root         120 Jul 19 06:11 dri
                          lrwxrwxrwx 1 root root           7 Jul 19 13:36 emmc -> mmcblk2
                          lrwxrwxrwx 1 root root          12 Jul 19 06:11 emmc-boot0 -> mmcblk2boot0
                          lrwxrwxrwx 1 root root          12 Jul 19 06:11 emmc-boot1 -> mmcblk2boot1
                          lrwxrwxrwx 1 root root           9 Jul 19 13:36 emmc-part1 -> mmcblk2p1
                          crw-rw---- 1 root video    29,   0 Jul 19 06:11 fb0
                          lrwxrwxrwx 1 root root          13 Jul 19 06:11 fd -> /proc/self/fd
                          crw-rw-rw- 1 root root      1,   7 Jul 19 06:11 full
                          crw-rw-rw- 1 root root     10, 229 Jul 19 06:11 fuse
                          crw-rw---- 1 root video   199,   0 Jul 19 06:11 galcore
                          crw-rw-r-- 1 root gpio    254,   0 Jul 19 06:11 gpiochip0
                          crw-rw-r-- 1 root gpio    254,   1 Jul 19 06:11 gpiochip1
                          crw-rw-r-- 1 root gpio    254,   2 Jul 19 06:11 gpiochip2
                          crw-rw-r-- 1 root gpio    254,   3 Jul 19 06:11 gpiochip3
                          crw-rw-r-- 1 root gpio    254,   4 Jul 19 06:11 gpiochip4
                          crw------- 1 root root    237,   0 Jul 19 12:57 hidraw0
                          crw------- 1 root root    237,   1 Jul 19 12:57 hidraw1
                          drwxr-xr-x 2 root root           0 Jul 19 06:11 hugepages
                          crw------- 1 root root     10, 183 Jul 19 06:11 hwrng
                          crw-rw-r-- 1 root i2cdev   89,   0 Jul 19 06:11 i2c-0
                          crw-rw-r-- 1 root i2cdev   89,   1 Jul 19 06:11 i2c-1
                          crw-rw-r-- 1 root i2cdev   89,   2 Jul 19 06:11 i2c-2
                          crw-rw-r-- 1 root i2cdev   89,   3 Jul 19 06:11 i2c-3
                          crw------- 1 root root    510,   0 Jul 19 06:11 iio:device0
                          lrwxrwxrwx 1 root root          12 Jul 19 06:11 initctl -> /run/initctl
                          drwxr-xr-x 4 root root         220 Jul 19 12:57 input
                          crw-r--r-- 1 root root      1,  11 Jul 19 06:11 kmsg
                          crw-rw-rw- 1 root kvm      10, 232 Jul 19 06:11 kvm
                          lrwxrwxrwx 1 root root          28 Jul 19 06:11 log -> /run/systemd/journal/dev-log
                          crw-rw---- 1 root disk     10, 237 Jul 19 06:11 loop-control
                          brw-rw---- 1 root disk      7,   0 Jul 19 06:11 loop0
                          brw-rw---- 1 root disk      7,   1 Jul 19 06:11 loop1
                          brw-rw---- 1 root disk      7,   2 Jul 19 06:11 loop2
                          brw-rw---- 1 root disk      7,   3 Jul 19 06:11 loop3
                          brw-rw---- 1 root disk      7,   4 Jul 19 06:11 loop4
                          brw-rw---- 1 root disk      7,   5 Jul 19 06:11 loop5
                          brw-rw---- 1 root disk      7,   6 Jul 19 06:11 loop6
                          brw-rw---- 1 root disk      7,   7 Jul 19 06:11 loop7
                          drwxr-xr-x 2 root root          60 Jul 19 06:11 mapper
                          crw-r----- 1 root kmem      1,   1 Jul 19 06:11 mem
                          brw-rw---- 1 root disk    179,   0 Jul 19 13:36 mmcblk2
                          brw-rw---- 1 root disk    179,  32 Jul 19 06:11 mmcblk2boot0
                          brw-rw---- 1 root disk    179,  64 Jul 19 06:11 mmcblk2boot1
                          brw-rw---- 1 root disk    179,   1 Jul 19 13:36 mmcblk2p1
                          crw------- 1 root root    238,   0 Jul 19 06:11 mmcblk2rpmb
                          drwxrwxrwt 2 root root          40 Jan  1  1970 mqueue
                          crw------- 1 root root    235,   0 Jul 19 06:11 mxc_hantro
                          crw------- 1 root root    234,   0 Jul 19 06:11 mxc_hantro_vc8000e
                          drwxr-xr-x 2 root root          60 Jul 19 06:11 net
                          crw-rw-rw- 1 root root      1,   3 Jul 19 06:11 null
                          crw-r----- 1 root kmem      1,   4 Jul 19 06:11 port
                          crw------- 1 root root    108,   0 Jul 19 06:11 ppp
                          crw-rw-rw- 1 root tty       5,   2 Jul 19 13:41 ptmx
                          crw------- 1 root root    248,   0 Jul 19 06:11 ptp0
                          drwxr-xr-x 2 root root           0 Jul 19 06:11 pts
                          crw------- 1 root root      2,   0 Jul 19 06:11 ptyp0
                          crw------- 1 root root      2,   1 Jul 19 06:11 ptyp1
                          crw------- 1 root root      2,   2 Jul 19 06:11 ptyp2
                          crw------- 1 root root      2,   3 Jul 19 06:11 ptyp3
                          crw------- 1 root root      2,   4 Jul 19 06:11 ptyp4
                          crw------- 1 root root      2,   5 Jul 19 06:11 ptyp5
                          crw------- 1 root root      2,   6 Jul 19 06:11 ptyp6
                          crw------- 1 root root      2,   7 Jul 19 06:11 ptyp7
                          crw------- 1 root root      2,   8 Jul 19 06:11 ptyp8
                          crw------- 1 root root      2,   9 Jul 19 06:11 ptyp9
                          crw------- 1 root root      2,  10 Jul 19 06:11 ptypa
                          crw------- 1 root root      2,  11 Jul 19 06:11 ptypb
                          crw------- 1 root root      2,  12 Jul 19 06:11 ptypc
                          crw------- 1 root root      2,  13 Jul 19 06:11 ptypd
                          crw------- 1 root root      2,  14 Jul 19 06:11 ptype
                          crw------- 1 root root      2,  15 Jul 19 06:11 ptypf
                          brw-rw---- 1 root disk      1,   0 Jul 19 06:11 ram0
                          brw-rw---- 1 root disk      1,   1 Jul 19 06:11 ram1
                          brw-rw---- 1 root disk      1,  10 Jul 19 06:11 ram10
                          brw-rw---- 1 root disk      1,  11 Jul 19 06:11 ram11
                          brw-rw---- 1 root disk      1,  12 Jul 19 06:11 ram12
                          brw-rw---- 1 root disk      1,  13 Jul 19 06:11 ram13
                          brw-rw---- 1 root disk      1,  14 Jul 19 06:11 ram14
                          brw-rw---- 1 root disk      1,  15 Jul 19 06:11 ram15
                          brw-rw---- 1 root disk      1,   2 Jul 19 06:11 ram2
                          brw-rw---- 1 root disk      1,   3 Jul 19 06:11 ram3
                          brw-rw---- 1 root disk      1,   4 Jul 19 06:11 ram4
                          brw-rw---- 1 root disk      1,   5 Jul 19 06:11 ram5
                          brw-rw---- 1 root disk      1,   6 Jul 19 06:11 ram6
                          brw-rw---- 1 root disk      1,   7 Jul 19 06:11 ram7
                          brw-rw---- 1 root disk      1,   8 Jul 19 06:11 ram8
                          brw-rw---- 1 root disk      1,   9 Jul 19 06:11 ram9
                          crw-rw-rw- 1 root root      1,   8 Jul 19 06:11 random
                          crw-rw-r-- 1 root root     10, 242 Jul 19 06:11 rfkill
                          lrwxrwxrwx 1 root root           4 Jul 19 06:11 rtc -> rtc0
                          crw------- 1 root root    252,   0 Jul 19 06:11 rtc0
                          crw------- 1 root root    252,   1 Jul 19 06:11 rtc1
                          drwxrwxrwt 2 root root         160 Jul 19 13:05 shm
                          drwxr-xr-x 3 root root         140 Jul 19 06:11 snd
                          lrwxrwxrwx 1 root root          15 Jul 19 06:11 stderr -> /proc/self/fd/2
                          lrwxrwxrwx 1 root root          15 Jul 19 06:11 stdin -> /proc/self/fd/0
                          lrwxrwxrwx 1 root root          15 Jul 19 06:11 stdout -> /proc/self/fd/1
                          crw-rw-rw- 1 root tty       5,   0 Jul 19 13:41 tty
                          crw--w---- 1 root tty       4,   0 Jul 19 06:11 tty0
                          crw--w---- 1 root tty       4,   1 Jul 19 06:12 tty1
                          crw--w---- 1 root tty       4,  10 Jul 19 06:11 tty10
                          crw--w---- 1 root tty       4,  11 Jul 19 06:11 tty11
                          crw--w---- 1 root tty       4,  12 Jul 19 06:11 tty12
                          crw--w---- 1 root tty       4,  13 Jul 19 06:11 tty13
                          crw--w---- 1 root tty       4,  14 Jul 19 06:11 tty14
                          crw--w---- 1 root tty       4,  15 Jul 19 06:11 tty15
                          crw--w---- 1 root tty       4,  16 Jul 19 06:11 tty16
                          crw--w---- 1 root tty       4,  17 Jul 19 06:11 tty17
                          crw--w---- 1 root tty       4,  18 Jul 19 06:11 tty18
                          crw--w---- 1 root tty       4,  19 Jul 19 06:11 tty19
                          crw--w---- 1 root tty       4,   2 Jul 19 06:11 tty2
                          crw--w---- 1 root tty       4,  20 Jul 19 06:11 tty20
                          crw--w---- 1 root tty       4,  21 Jul 19 06:11 tty21
                          crw--w---- 1 root tty       4,  22 Jul 19 06:11 tty22
                          crw--w---- 1 root tty       4,  23 Jul 19 06:11 tty23
                          crw--w---- 1 root tty       4,  24 Jul 19 06:11 tty24
                          crw--w---- 1 root tty       4,  25 Jul 19 06:11 tty25
                          crw--w---- 1 root tty       4,  26 Jul 19 06:11 tty26
                          crw--w---- 1 root tty       4,  27 Jul 19 06:11 tty27
                          crw--w---- 1 root tty       4,  28 Jul 19 06:11 tty28
                          crw--w---- 1 root tty       4,  29 Jul 19 06:11 tty29
                          crw--w---- 1 root tty       4,   3 Jul 19 06:11 tty3
                          crw--w---- 1 root tty       4,  30 Jul 19 06:11 tty30
                          crw--w---- 1 root tty       4,  31 Jul 19 06:11 tty31
                          crw--w---- 1 root tty       4,  32 Jul 19 06:11 tty32
                          crw--w---- 1 root tty       4,  33 Jul 19 06:11 tty33
                          crw--w---- 1 root tty       4,  34 Jul 19 06:11 tty34
                          crw--w---- 1 root tty       4,  35 Jul 19 06:11 tty35
                          crw--w---- 1 root tty       4,  36 Jul 19 06:11 tty36
                          crw--w---- 1 root tty       4,  37 Jul 19 06:11 tty37
                          crw--w---- 1 root tty       4,  38 Jul 19 06:11 tty38
                          crw--w---- 1 root tty       4,  39 Jul 19 06:11 tty39
                          crw--w---- 1 root tty       4,   4 Jul 19 06:11 tty4
                          crw--w---- 1 root tty       4,  40 Jul 19 06:11 tty40
                          crw--w---- 1 root tty       4,  41 Jul 19 06:11 tty41
                          crw--w---- 1 root tty       4,  42 Jul 19 06:11 tty42
                          crw--w---- 1 root tty       4,  43 Jul 19 06:11 tty43
                          crw--w---- 1 root tty       4,  44 Jul 19 06:11 tty44
                          crw--w---- 1 root tty       4,  45 Jul 19 06:11 tty45
                          crw--w---- 1 root tty       4,  46 Jul 19 06:11 tty46
                          crw--w---- 1 root tty       4,  47 Jul 19 06:11 tty47
                          crw--w---- 1 root tty       4,  48 Jul 19 06:11 tty48
                          crw--w---- 1 root tty       4,  49 Jul 19 06:11 tty49
                          crw--w---- 1 root tty       4,   5 Jul 19 06:11 tty5
                          crw--w---- 1 root tty       4,  50 Jul 19 06:11 tty50
                          crw--w---- 1 root tty       4,  51 Jul 19 06:11 tty51
                          crw--w---- 1 root tty       4,  52 Jul 19 06:11 tty52
                          crw--w---- 1 root tty       4,  53 Jul 19 06:11 tty53
                          crw--w---- 1 root tty       4,  54 Jul 19 06:11 tty54
                          crw--w---- 1 root tty       4,  55 Jul 19 06:11 tty55
                          crw--w---- 1 root tty       4,  56 Jul 19 06:11 tty56
                          crw--w---- 1 root tty       4,  57 Jul 19 06:11 tty57
                          crw--w---- 1 root tty       4,  58 Jul 19 06:11 tty58
                          crw--w---- 1 root tty       4,  59 Jul 19 06:11 tty59
                          crw--w---- 1 root tty       4,   6 Jul 19 06:11 tty6
                          crw--w---- 1 root tty       4,  60 Jul 19 06:11 tty60
                          crw--w---- 1 root tty       4,  61 Jul 19 06:11 tty61
                          crw--w---- 1 root tty       4,  62 Jul 19 06:11 tty62
                          crw--w---- 1 root tty       4,  63 Jul 19 06:11 tty63
                          crw--w---- 1 root tty       4,   7 Jul 19 06:11 tty7
                          crw--w---- 1 root tty       4,   8 Jul 19 06:11 tty8
                          crw--w---- 1 root tty       4,   9 Jul 19 06:11 tty9
                          crw-rw---- 1 root dialout   4,  64 Jul 19 06:11 ttyS0
                          crw-rw---- 1 root dialout   4,  65 Jul 19 06:11 ttyS1
                          crw-rw---- 1 root dialout   4,  66 Jul 19 06:11 ttyS2
                          crw-rw---- 1 root dialout   4,  67 Jul 19 06:11 ttyS3
                          crw-rw---- 1 root dialout 207,  16 Jul 19 06:11 ttymxc0
                          crw-rw---- 1 root dialout 207,  17 Jul 19 06:11 ttymxc1
                          crw-rw---- 1 root dialout 207,  18 Jul 19 06:12 ttymxc2
                          crw------- 1 root root      3,   0 Jul 19 06:11 ttyp0
                          crw------- 1 root root      3,   1 Jul 19 06:11 ttyp1
                          crw------- 1 root root      3,   2 Jul 19 06:11 ttyp2
                          crw------- 1 root root      3,   3 Jul 19 06:11 ttyp3
                          crw------- 1 root root      3,   4 Jul 19 06:11 ttyp4
                          crw------- 1 root root      3,   5 Jul 19 06:11 ttyp5
                          crw------- 1 root root      3,   6 Jul 19 06:11 ttyp6
                          crw------- 1 root root      3,   7 Jul 19 06:11 ttyp7
                          crw------- 1 root root      3,   8 Jul 19 06:11 ttyp8
                          crw------- 1 root root      3,   9 Jul 19 06:11 ttyp9
                          crw------- 1 root root      3,  10 Jul 19 06:11 ttypa
                          crw------- 1 root root      3,  11 Jul 19 06:11 ttypb
                          crw------- 1 root root      3,  12 Jul 19 06:11 ttypc
                          crw------- 1 root root      3,  13 Jul 19 06:11 ttypd
                          crw------- 1 root root      3,  14 Jul 19 06:11 ttype
                          crw------- 1 root root      3,  15 Jul 19 06:11 ttypf
                          crw------- 1 root root     10, 124 Jul 19 06:11 ubi_ctrl
                          crw------- 1 root root     10, 223 Jul 19 06:11 uinput
                          crw-rw-rw- 1 root root      1,   9 Jul 19 06:11 urandom
                          drwxr-xr-x 2 root root          60 Jul 19 12:57 usb
                          drwxr-xr-x 3 root root          60 Jul 19 06:11 v4l
                          crw-rw---- 1 root tty       7,   0 Jul 19 06:11 vcs
                          crw-rw---- 1 root tty       7,   1 Jul 19 06:11 vcs1
                          crw-rw---- 1 root tty       7,   2 Jul 19 06:11 vcs2
                          crw-rw---- 1 root tty       7,   3 Jul 19 06:11 vcs3
                          crw-rw---- 1 root tty       7,   4 Jul 19 06:11 vcs4
                          crw-rw---- 1 root tty       7,   5 Jul 19 06:11 vcs5
                          crw-rw---- 1 root tty       7,   6 Jul 19 06:11 vcs6
                          crw-rw---- 1 root tty       7,   7 Jul 19 07:05 vcs7
                          crw-rw---- 1 root tty       7, 128 Jul 19 06:11 vcsa
                          crw-rw---- 1 root tty       7, 129 Jul 19 06:11 vcsa1
                          crw-rw---- 1 root tty       7, 130 Jul 19 06:11 vcsa2
                          crw-rw---- 1 root tty       7, 131 Jul 19 06:11 vcsa3
                          crw-rw---- 1 root tty       7, 132 Jul 19 06:11 vcsa4
                          crw-rw---- 1 root tty       7, 133 Jul 19 06:11 vcsa5
                          crw-rw---- 1 root tty       7, 134 Jul 19 06:11 vcsa6
                          crw-rw---- 1 root tty       7, 135 Jul 19 07:05 vcsa7
                          crw-rw---- 1 root tty       7,  64 Jul 19 06:11 vcsu
                          crw-rw---- 1 root tty       7,  65 Jul 19 06:11 vcsu1
                          crw-rw---- 1 root tty       7,  66 Jul 19 06:11 vcsu2
                          crw-rw---- 1 root tty       7,  67 Jul 19 06:11 vcsu3
                          crw-rw---- 1 root tty       7,  68 Jul 19 06:11 vcsu4
                          crw-rw---- 1 root tty       7,  69 Jul 19 06:11 vcsu5
                          crw-rw---- 1 root tty       7,  70 Jul 19 06:11 vcsu6
                          crw-rw---- 1 root tty       7,  71 Jul 19 07:05 vcsu7
                          lrwxrwxrwx 1 root root          94 Jul 19 06:11 verdin-adc1 -> /sys/devices/platform/soc@0/30800000.bus/30a20000.i2c/i2c-0/0-0049/iio:device0/in_voltage3_raw
                          lrwxrwxrwx 1 root root          94 Jul 19 06:11 verdin-adc2 -> /sys/devices/platform/soc@0/30800000.bus/30a20000.i2c/i2c-0/0-0049/iio:device0/in_voltage2_raw
                          lrwxrwxrwx 1 root root          94 Jul 19 06:11 verdin-adc3 -> /sys/devices/platform/soc@0/30800000.bus/30a20000.i2c/i2c-0/0-0049/iio:device0/in_voltage1_raw
                          lrwxrwxrwx 1 root root          94 Jul 19 06:11 verdin-adc4 -> /sys/devices/platform/soc@0/30800000.bus/30a20000.i2c/i2c-0/0-0049/iio:device0/in_voltage0_raw
                          lrwxrwxrwx 1 root root           5 Jul 19 06:11 verdin-i2c-on-module -> i2c-0
                          lrwxrwxrwx 1 root root           5 Jul 19 06:11 verdin-i2c1 -> i2c-3
                          lrwxrwxrwx 1 root root           5 Jul 19 06:11 verdin-i2c2 -> i2c-1
                          lrwxrwxrwx 1 root root           5 Jul 19 06:11 verdin-i2c4 -> i2c-2
                          lrwxrwxrwx 1 root root           7 Jul 19 06:11 verdin-uart1 -> ttymxc0
                          lrwxrwxrwx 1 root root           7 Jul 19 06:11 verdin-uart2 -> ttymxc1
                          lrwxrwxrwx 1 root root           7 Jul 19 06:11 verdin-uart3 -> ttymxc2
                          lrwxrwxrwx 1 root root           8 Jul 19 06:11 verdin-watchdog -> watchdog
                          lrwxrwxrwx 1 root root           9 Jul 19 06:11 verdin-watchdog-soc -> watchdog0
                          drwxr-xr-x 2 root root          60 Jan  1  1970 vfio
                          crw------- 1 root root     10, 127 Jul 19 06:11 vga_arbiter
                          crw------- 1 root root     10, 137 Jul 19 06:11 vhci
                          crw-rw---- 1 root video    81,   0 Jul 19 06:11 video0
                          crw-rw---- 1 root video    81,   1 Jul 19 06:11 video1
                          crw------- 1 root root    100,   0 Jul 19 06:11 vsi_daemon_ctrl
                          crw------- 1 root root     10, 130 Jul 19 06:11 watchdog
                          crw------- 1 root root    246,   0 Jul 19 06:11 watchdog0
                          crw-rw-rw- 1 root root      1,   5 Jul 19 06:11 zero
                          brw-rw---- 1 root disk    253,   0 Jul 19 06:11 zram0
------------------------------------------------------------
torizon@verdin-imx8mp-15229850:~$ 

Sincerely,
François.

Hi @matheus.tx and @flepron

Thanks for the info about docker-compose and device identifiers.
I managed to get your AvaloniaUITheSeriesGTKMVVM container working, but it’s quite slow; when I press the buttons the response times are quite long.

Now I tried to create a new project using the “Avalonia Frame Buffer DRM” Template, with only a few buttons drawn and one of these writes “Click” in the console when pressed.

The click response times of this project are good.
But if I leave the container active without pressing any buttons for an hour and then start pressing the buttons, the application freezes and no longer responds to the click.
So I tried to run the “top” command in SSH and I see the “containerd”, “containerd-shim” and “dockerd” processes that continue to appear and disappear with VIRT column values ​​greater than 900,000, while the process of my “avaloniafbtest” application is not present.

I’m continuing to do other tests, but I’m afraid that avalonia is too heavy for this SoM.

Thank you in advance
Best regards,
Filippo

Hi @Filippo-GEG

Maybe @matheus.tx can give you a better analysis of what you’re observing using top or htop, but I am not skilled enough to give you a significant explanation.

But, I will make the test during one hour of inactivity with my application using FB DRM which is the same as the GTK MVVM App but converted into FB DRM. FLepron-PoolCop/AvaloniaUITheSeriesFBDRM (github.com), and I will let you know what’s going on.

This could be useful for you, because I have one of the more powerful Toradex’s SOM (Verdin i.MX 8MX Plus). If I have an issue, this may come from a configuration problem in the App, else you’re SOM is too limited or there is a specific configuration in your setup not compliant with Avalonia UI App Inactivity.

One question @Filippo-GEG : have you been able to activate the pointer of your mouse in your FB DRM app, because in this mode I do not see the pointer of my mouse, whereas in GTK MVVM, I see it without problem ?

Regards,
François.