Avalonia application running in Weston type Window

jon2023 · November 27, 2023, 4:19pm

Hi there,

Hardware:
Colibri iMX6DL
with Viola Carrier Board Rev 1.2
TorizonCore 5.7.2

I’ve run through some of the weston examples, i.e. the weston-eventdemo etc. from github

and most of them run within a weston container/window with a title bar, min/max/close button with sizeable borders.

I’ve then run the Analonia wizard and create a basic “Hello Analonia” .NET application with Dockerfile/Dockerfile.debug, docker-compose.yml files and can run the “full” screen application on the colibri board.

Would it be possible to run the Analonia docker within a weston container/window?
If so, what would be the first steps.

Cheers Jon

leon.tx · November 27, 2023, 5:46pm

Hello there!

Would it be possible to run the Analonia docker within a weston container/window?

If I understood correctly, you want to specifically run with the title bar, min/max/close button etc?

You can do that by passing --developer with command in your docker-compose.yml like

  weston:
    image: torizon/weston${GPU}:3
    command: --developer

This brings up the weston shell instead of a blank canvas (which is where your fullscreen Avalonia application is running, by the way!).

jon2023 · November 27, 2023, 6:11pm

Hi there leon,

My docker-compose.yml (generated by the Avalonia .NET wizard) looks more like this…

version: “3.9”
services:
avalonia13-debug:
build:
context: .
dockerfile: Dockerfile.debug
image: ${LOCAL_REGISTRY}:5002/avalonia13:${TAG}
environment:
- XDG_RUNTIME_DIR=/run/display
# Required to get udev events from host udevd via netlink
network_mode: host
volumes:
- type: bind
source: /tmp
target: /tmp
- type: bind

Not sure how to update it to “link” (if that’s the correct) the “weston” image with the current image link in the docker-compose.yml above.

services:
avalonia13-debug: <— !!!
build:
context: .
dockerfile: Dockerfile.debug
image: ${LOCAL_REGISTRY}:5002/avalonia13:${TAG} <— !!!

Many Thanks Jon

leon.tx · November 27, 2023, 6:37pm

Hi again

Avalonia .NET wizard

Just some background info: you’re using the Torizon IDE Extension and created a new Avalonia project, correct?

leon.tx · November 27, 2023, 6:43pm

By the way: the target for the new IDE extension is Torizon OS 6.x.y as defined here IDE Extension | Toradex Developer Center.

If feasible, please consider updating to Torizon OS 6.x.y following this documentation: Upgrading from TorizonCore 5.x to Torizon OS 6.x | Toradex Developer Center.

jon2023 · November 27, 2023, 9:57pm

Hi leon,

Yeah, using the new Torizon IDE Extension…

… its pretty easy to use, and gives a good starting point

Cheers Jon

jon2023 · November 27, 2023, 9:59pm

Hi leon,

Thanks for the message. I think upgrading to Torizon OS 6.x.y would be a good thing to do.
I’ll take a look at the steps and see how it goes

Cheers Jon

jon2023 · November 28, 2023, 10:18am

Good Morning leon,

While my colleague looks at the upgrade path on a second board which we have, I’m looking into the docker-compose.yml changes for running the Avalonia application in a weston window/container as a PoC, but not sure how it should be updated. Are there any examples I take a look at?

Cheers Jon

henrique.tx · November 28, 2023, 2:45pm

Hi @jon2023 !

All the templates we have on Torizon IDE will give you a containerized application.

Best regards,

jon2023 · November 28, 2023, 7:10pm

Hi henrique,

We’ve created a new Avalonia application using the Wizard…

Which creates all the project files, Dockerfile, Dockerfile.debug, docker-compose.yml etc. etc.

When we debug the application from VisualStudioCode, it runs on the device and the UI is displayed “Full” screen on the LCD display…

And checking the docker container…
$ docker ps

We would like to see the Avalonia application (if that’s possible) to run inside a window with a title bar, min, max & close buttons…

Is it possible to make some minor updates to the docker-compose.yml file to achieve this, or is it not as simple as that?

docker-compose.yml
version: "3.9"
services:
  avalonia13-debug:
    build:
        context: .
        dockerfile: Dockerfile.debug
    image: ${LOCAL_REGISTRY}:5002/avalonia13:${TAG}
    environment:
      - XDG_RUNTIME_DIR=/run/display
    # 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
      - type: bind
        source: /dev/input
        target: /dev/input
      - type: bind
        source: /dev/input/event0
        target: /dev/input/event0
      - type: bind
        source: /dev/input/event1
        target: /dev/input/event1
      - type: bind
        source: /dev/input/touchscreen0
        target: /dev/input/touchscreen0
      - type: bind
        source: /run/udev/data
        target: /run/udev/data
      - type: bind
        source: /etc/xdg/weston
        target: /etc/xdg/weston
      - type: bind
        source: /etc/xdg/weston-dev
        target: /etc/xdg/weston-dev

      - type: bind
        source: /etc/xdg/weston/weston.ini
        target: /etc/xdg/weston/weston.ini

      - type: bind
        source: /etc/xdg/weston-dev/weston.ini
        target: /etc/xdg/weston-dev/weston.ini

    devices:        
      - "/dev/input:/dev/input"
      - "/dev/input/event0:/dev/input/event0"
      - "/dev/input/event1:/dev/input/event1"
      - "/dev/input/touchscreen0:/dev/input/touchscreen0"
      - "/dev/gpiochip0"
      - "/dev/gpiochip1"
      - "/dev/gpiochip4"
      - "/dev/spidev3.0"

    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"

      - "c 4:1 rmw"
      # ... for /dev/input devices
      - "c 13:* rmw"
      # ... for /dev/dri devices
      - "c 226:* rmw"
      - "c 199:* rmw"
      # ... for /dev/fb0
      - "c 29:* rmw"

      # ... for /dev/input/touchscreen0 devices
      - "c 6:* rmw"

  avalonia13:
    build:
        context: .
        dockerfile: Dockerfile
    image: ${DOCKER_LOGIN}/avalonia13:${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"

Cheers Jon

leon.tx · November 29, 2023, 1:59pm

Hi again Jon!

We would like to see the Avalonia application (if that’s possible) to run inside a window with a title bar, min, max & close buttons…

You’re using the framebuffer template, which won’t use a compositor (like Weston) so it doesn’t have the title bars etc.

You can achieve this effect by using the other Avalonia template (the one with no “framebuffer” in the title) and just edit the generated docker-compose.yml according to this Avalonia application running in Weston type Window - #4 by leon.tx.

It’s a bit odd why you’re getting these Weston mentions from the AvaloniaFB template. The docker-compose.yml you should get is this one: https://github.com/toradex/vscode-torizon-templates/blob/bookworm/dotnetAvaloniaFrameBuffer/docker-compose.yml.

Cheers,

henrique.tx · November 29, 2023, 2:22pm

Hi @jon2023!

Out of curiosity, could you please shre why would you like to have such decoration around your application’s UI?
Usually (if not always) embedded applications are fullscreen to forbid users to change its visual and also make a more efficient usage of the display area.

Best regards,

jon2023 · November 29, 2023, 3:09pm

Hi henrique,

We current have a Avalonia application running on a portrait LCD display (240x320).
But we need to mount the LCD display in Landscape where the current origin is at the bottom-left hand corner

We are looking at different options to rotate the display.
Options

Rotate the UI in software - Which is working, but not ideal at design time
If possible, host the Avalonia application inside a weston window and set the weston.ini (weston-dev.ini) to support the rotate setting.
Open to any other ideas which we can try out

Cheers Jon

henrique.tx · November 29, 2023, 8:41pm

Hi @jon2023 !

I would say that the easier way is to configure Weston to rotate the display for you. We have this article that explains how to do so: Working with Weston on Torizon OS | Toradex Developer Center

But keep in mine the tip from @leon.tx:

But I still didn’t understand why you would want the min/max/close buttons plus the decoration around your application

Best regards,

jon2023 · November 29, 2023, 10:34pm

Hi there leon, not sure what you mean by “just edit…” edit the docker-compose.yml file to include what exactly?

We trying to resolve two problematic issues, the orientation & touch support and looking to eliminate if its a configuration issue, i.e. is the weston.ini correctly working to apply the rotate setting and is the touch device tree overlay applied and working. The (weston) “window” examples show these are work ok, but the Avalonia (wizard) example (with TorizonCore v5.7.1) show issues.

Showing that the (weston) “window” is working for both the orientation and touch is a useful diagnostic step in eliminating the setup/config.

It seems that the suggestion to upgrade to Torizon OS 6.x.y might help with both of these issues which are currently looking into.

Cheers Jon

leon.tx · November 30, 2023, 12:35pm

Hi Jon,
quite literally to open up the generated docker-compose.yml file (after setting up a project) and paste the command: --developer line under the weston: service, like so

...
  weston:
    image: torizon/weston${GPU}:3
    command: --developer
...

Again, you’re not gonna get a weston service with the Frambuffer example, because it just draws things on screen without a compositor (which is weston). The --developer flag makes the title bars etc appear on the screen just as you want.

Let us know how it goes!

jon2023 · December 1, 2023, 1:26pm

Hi there,

The generated docker-compose.yml file (from the Analonia wizard) don’t seem to have the “weston:…” section (under the services: node)…

Or is there something I’m missing?

version: "3.9"
services:
  avalonia13-debug:                                              <--- 
    build:
        context: .
        dockerfile: Dockerfile.debug
    image: ${LOCAL_REGISTRY}:5002/avalonia13:${TAG}
    environment:
      - XDG_RUNTIME_DIR=/run/display
    # 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
      - type: bind
        source: /dev/input
        target: /dev/input
      - type: bind
        source: /dev/input/event0
        target: /dev/input/event0
      - type: bind
        source: /run/udev/data
        target: /run/udev/data
      - type: bind
        source: /etc/xdg/weston
        target: /etc/xdg/weston
      - type: bind
        source: /etc/xdg/weston-dev
        target: /etc/xdg/weston-dev

      - type: bind
        source: /etc/xdg/weston/weston.ini
        target: /etc/xdg/weston/weston.ini

      - type: bind
        source: /etc/xdg/weston-dev/weston.ini
        target: /etc/xdg/weston-dev/weston.ini

    devices:        
      - "/dev/input:/dev/input"
      - "/dev/input/event0:/dev/input/event0"
      - "/dev/gpiochip0"
      - "/dev/gpiochip1"
      - "/dev/gpiochip4"
      - "/dev/spidev3.0"

    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"

      - "c 4:1 rmw"
      # ... for /dev/input devices
      - "c 13:* rmw"
      # ... for /dev/dri devices
      - "c 226:* rmw"
      - "c 199:* rmw"
      # ... for /dev/fb0
      - "c 29:* rmw"

      # ... for /dev/input/touchscreen0 devices
      - "c 6:* rmw"

  avalonia13:                                                 <---
    build:
        context: .
        dockerfile: Dockerfile
    image: ${DOCKER_LOGIN}/avalonia13:${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"

henrique.tx · December 4, 2023, 5:15pm

Hi @jon2023 !

I just created a project from the “.Net 6 C# Avalonia GTK MVVM” Torizon IDE template and the docker-compose.yml isn’t similar to yours.

Here it is:

version: "3.9"
services:
  apagar-debug:
    build:
      context: .
      dockerfile: Dockerfile.debug
    image: ${LOCAL_REGISTRY}:5002/apagar:${TAG}
    ports:
      - 2223:2223
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /dev
        target: /dev
    device_cgroup_rules:
      # ... for tty0
      - "c 4:0 rmw"
      # ... for tty7
      - "c 4:7 rmw"
      # ... for /dev/input devices
      - "c 13:* rmw"
      - "c 199:* rmw"
      # ... for /dev/dri devices
      - "c 226:* rmw"
    depends_on: [
      weston
    ]

  apagar:
    build:
      context: .
      dockerfile: Dockerfile
    image: ${DOCKER_LOGIN}/apagar:${TAG}
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /dev
        target: /dev
    device_cgroup_rules:
      # ... for tty0
      - "c 4:0 rmw"
      # ... for tty7
      - "c 4:7 rmw"
      # ... for /dev/input devices
      - "c 13:* rmw"
      - "c 199:* rmw"
      # ... for /dev/dri devices
      - "c 226:* rmw"
    depends_on: [
      weston
    ]

# TODO: we are using bullseye here because an issue with xwayland on bookworm
  weston:
    image: torizon/weston${GPU}:2
    environment:
      - ACCEPT_FSL_EULA=1
    # 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 tty1
      - "c 4:1 rmw"
      # ... for tty7
      - "c 4:7 rmw"
      # ... for /dev/input devices
      - "c 13:* rmw"
      - "c 199:* rmw"
      # ... for /dev/dri devices
      - "c 226:* rmw"

As you can see, there is a weston container, which isn’t present in your docker-compose.yml.

So I would guess you are not following @leon.tx’s advice.

Best regards,