Application unable to use wayland

Technical Support
, , , ,
1

At startup system loads services from the
docker-compose.yml

version: "2.4"
services:
  weston:
#... (environment)
    container_name: weston
    image: ibragimovingasm/nobilis-weston
#... (bindings)
    cap_add:
      - CAP_SYS_TTY_CONFIG
    command: --developer weston-launch --tty=/dev/tty7 --user=torizon
    # Add device access rights through group...

portainer:
# ... (typical)

 nobilis-client:
    container_name: nobilis-client
    image: ibragimovingasm/nobilis-client
    security_opt:
      - seccomp:unconfined    
    network_mode: host
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /var/run/dbus
        target: /var/run/dbus
      - type: bind
        source: /dev/dri
        target: /dev/dri
      - type: bind
        source: /dev
        target: /dev
      - type: bind
        source: /run/udev
        target: /run/udev
      - type: bind
        source: /sys/class/gpio
        target: /sys/class/gpio
      - type: bind
        source: /home/torizon/nobilis_work_dir/data_pers.sqlite
        target: /opt/Nobilis_client/bin/data_pers.sqlite
      - type: bind
        source: /home/torizon/nobilis_work_dir/settings.xml
        target: /opt/Nobilis_client/bin/settings.xml
    devices:
#...
    privileged: true
    depends_on:
      - weston
    shm_size: '256mb'
    device_cgroup_rules:
      - 'c 4:* rmw'
      - 'c 13:* rmw'
      # ... for /dev/dri devices
      - 'c 226:* rmw'
      
volumes:
  portainer_data:

weston start OK - display resolution, background
but Qt/QML application fails with

~$ docker logs nobilis-client 
QML debugging is enabled. Only use this in a safe environment.
Failed to create wl_display (No such file or directory)
qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, xcb.
/entrypoint.sh: line 4:     7 Aborted                 (core dumped) ./Nobilis_client --arch ixora

If I login to the ssh terminal, stop weston and run the same docker-compose.yml then weston and application start successfully.

In the docker-compose.yml I have set depends_on: weston
I use command: --developer weston-launch --tty=/dev/tty7 --user=torizon because I could not set resolution without --developer yet

I try to add into entrypoint.sh of application

sleep 8

it starts. But it is the wrong way.

Obviously, weston does not ready yet at the moment of the request for service resources.
But depends_on: weston is not enough for waiting for the readiness of the service.

How to define the right sequence of starting weston and Qt GUI application?

weston Docker

weston entry.sh

app Docker

app entrypoint.sh

2

Greetings @Juzujka,

Actually this isn’t too far from what we do. On our non-Torizon multimedia reference image we start a Qt-based app on boot. However we use the following script to ensure that wayland is up and running before we start the Qt app: wayland-app-launch.sh.in « wayland-app-launch « wayland-app-launch « recipes-graphics - meta-toradex-demos.git - Toradex BSP layer, recipes for the demo images

Unfortunately the depends_on argument only waits for the weston container to start. It doesn’t wait for any processes in that container to reach a certain state. Therefore little tricks like this are required to ensure things start in a proper order.

Best Regards,
Jeremias

3

Chiming in with the better solution hidden in the Torizon docs: docker-compose depends_on supports a “condition” field, which must have a corresponding “healthcheck” setup in the other container.

See the example YAML files here: TorizonCore Builder Overview | Toradex Developer Center

This is tested working on my QT-wayland app.

4

Thank you for the improved suggestion. This is definitely the more robust solution. We’ve actually updated all our multi-container examples to use the health-check feature when applicable.