Qt5 Applicaition on imx8mp

Technical Support
,
1

Hi,

I’m trying to run a qt quick application using the torizon/qt5-wayland-imx8:stable-rc and torizon/weston-imx8:stable-rc containers.

The application crash on start with the following:

QT_QPA_PLATFORM= "wayland"
Failed to create wl_display (Connection refused)
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, wayland-xcomposite-glx, xcb.

tdxinfo is:

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           5.15.148-6.7.0+git.bfdbfb2c85fb #1-TorizonCore SMP PREEMPT Thu Jun 20 15:59:41 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/e81878773da7cb84df22dfc3108fa98703a54183a50b88c0eeb46705d5d934b7/0
Distro name:              NAME="TorizonCore"
Distro version:           VERSION_ID=6.7.0-build.18
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-imx8mp-15364500
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus on Mallow Board
Toradex version:          0063 V1.1B
Serial number:            15364500
Processor arch:           aarch64
------------------------------------------------------------

and my docker compose is:

volumes:
  permanent_storage:
services:
  mk3-debug:
    build:
      context: .
      dockerfile: Dockerfile.debug
    image: ${LOCAL_REGISTRY}:5002/mk3-debug:${TAG}
    ports:
      - ${DEBUG_SSH_PORT}:${DEBUG_SSH_PORT}
    profiles:
      - debug
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /dev
        target: /dev
      - type: bind
        source: /var
        target: /var
      - type: volume
        source: permanent_storage
        target: /home/root/app/permanent_data
    depends_on: [
      weston
    ]
    privileged: true

  weston:
    image: torizon/weston-imx8:stable-rc
    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"
2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Solution for Qt5 Wayland Connection Issue

The error you’re encountering is a common Wayland connection issue. Based on your setup with Verdin iMX8M Plus and Torizon OS 6.7.0, here are the key fixes:

1. Update Container Images

For Torizon OS 6.7.0, you should use the versioned container tags instead of stable-rc. The recommended containers for your iMX8M Plus are (1):

  • Weston: torizon/weston-imx8:4
  • Qt5: torizon/qt5-wayland-vivante (for iMX8 modules with Vivante GPU)

2. Fix Docker Compose Configuration

Your current docker-compose is missing critical device access rules. Here’s the corrected Weston service configuration (2):

weston:
  image: torizon/weston-imx8:4
  environment:
    - ACCEPT_FSL_EULA=1
  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
  device_cgroup_rules:
    - "c 4:* rmw"
    - "c 253:* rmw"
    - "c 13:* rmw"
    - "c 226:* rmw"
    - "c 10:223 rmw"
    - "c 199:0 rmw"
  command: --developer

3. Qt Application Container Configuration

For your Qt5 application container, ensure you’re using the correct base image and environment variables (3):

mk3-debug:
  # Use Qt5 Wayland container as base
  # Set QT_QPA_PLATFORM environment variable
  environment:
    - QT_QPA_PLATFORM=wayland
  volumes:
    - type: bind
      source: /tmp
      target: /tmp
  depends_on:
    - weston

4. Verify Wayland Socket

The “Connection refused” error typically occurs when:

  • Weston isn’t running properly
  • The Wayland socket /tmp/wayland-0 isn’t accessible
  • Missing device permissions for GPU access

5. Test with Qt Examples

To verify your setup works, you can test with the Qt5 examples container (1):

docker run --rm -it --name=qt5 \
  -v /tmp:/tmp \
  -v /dev/dri:/dev/dri -v /dev/galcore:/dev/galcore \
  --device-cgroup-rule='c 199:* rmw' --device-cgroup-rule='c 226:* rmw' \
  torizon/qt5-wayland-examples-vivante:3 \
  bash

Then inside the container, run:

/usr/lib/aarch64-linux-gnu/qt5/examples/widgets/widgets/calculator/calculator &

This should help resolve the Wayland connection issue you’re experiencing.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

@ToradexAI

here is the result of your proposed solutions:

  1. could you provide the tag to use on the Qt5 container for Torizon OS 6.7+ ? could you also provide a reference for compatibility tracking between the Torizon OS versions and the containers tags ?
  2. This solution did not work, the application still crash with the same error message
  3. The environment variable QT_QPA_PLATFORM was already set as you could see in the provided log. Using the base container image from your answer 1 resulted in the same error message.
  4. could you please expand on this and tell how to check if /tmp/wayland-0 is accessible and how to make it accessible if it is not. Can you also explain how to check the device permission for GPU access ?
4

Detailed Solutions for Qt5 Wayland Connection Issue

1. Qt5 Container Tags and Compatibility

For your Torizon OS 6.7.0 setup, you should use environment variables for container tags (1). The correct Qt5 container for your iMX8M Plus is:

  • Qt5 container: torizon/qt5-wayland-imx8:$CT_TAG_QT5_WAYLAND (2)

You can check the available environment variables on your device with (1):

# env | grep CT_TAG

For compatibility tracking between Torizon OS versions and container tags, refer to the Torizon Containers Tags and Versioning documentation (1).

2. Complete Docker Compose Configuration

Here’s the corrected docker-compose configuration for iMX8 with all required device access rules (3):

services:
  mk3-debug:
    build:
      context: .
      dockerfile: Dockerfile.debug
    environment:
      - QT_QPA_PLATFORM=wayland
      - ACCEPT_FSL_EULA=1
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /dev
        target: /dev
    device_cgroup_rules:
      - "c 4:* rmw"
      - "c 13:* rmw"
      - "c 199:* rmw"
      - "c 226:* rmw"
    depends_on:
      - weston

  weston:
    image: torizon/weston-imx8:4
    environment:
      - ACCEPT_FSL_EULA=1
    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
    device_cgroup_rules:
      - "c 4:* rmw"
      - "c 253:* rmw"
      - "c 13:* rmw"
      - "c 226:* rmw"
      - "c 10:223 rmw"
      - "c 199:0 rmw"
    command: --developer

(3)

3. Checking Wayland Socket Accessibility

To verify if the Wayland socket is accessible:

  1. Check if Weston is running properly:

    docker logs weston

    (3)

  2. Verify Wayland socket creation:

    ls -la /tmp/wayland-*

  3. Check Weston socket directory:

    ls -la /tmp/1000-runtime-dir/

    (3)

4. GPU Device Permission Verification

For iMX8 modules with Vivante GPU, ensure these device accesses (4):

  1. Check GPU device availability:

    ls -la /dev/galcore
ls -la /dev/dri/

  2. Verify device permissions in your Qt container:

    docker exec mk3-debug ls -la /dev/galcore
docker exec mk3-debug ls -la /dev/dri/

  3. Add missing device access to your Qt container (4):

    mk3-debug:
  volumes:
    - /dev/galcore:/dev/galcore
    - /dev/dri:/dev/dri
  device_cgroup_rules:
    - "c 199:* rmw"  # for /dev/galcore
    - "c 226:* rmw"  # for /dev/dri devices

5. Testing with Qt5 Examples

To verify your setup works, test with the Qt5 examples container (4):

docker run -e ACCEPT_FSL_EULA=1 --rm -it --name=qt5 \
           -v /tmp:/tmp \
           -v /dev/dri:/dev/dri -v /dev/galcore:/dev/galcore \
           --device-cgroup-rule='c 199:* rmw' --device-cgroup-rule='c 226:* rmw' \
           torizon/qt5-wayland-examples-imx8:$CT_TAG_QT5_WAYLAND_EXAMPLES \
           bash

(4)

Then inside the container:

/usr/lib/aarch64-linux-gnu/qt5/examples/widgets/widgets/calculator/calculator &

(4)

The key issue is likely missing GPU device access (/dev/galcore) and proper device cgroup rules for your Qt application container.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

5

@ToradexAI

  1. This answer is conflicting with the previous one. you previously said I should use the torizon/weston-imx8:4 image with torizon OS 6.7.0, but running env | grep WESTON on my board return CT_TAG_WESTON=3

  2. .

  3. running docker logs weston return the following:
    Switching VT tty1 to text mode if currently in graphics mode
    Switching to VT 7
    SoC is: ‘i.MX8MP’
    SoC has GPU: true
    SoC has DPU: false
    g2d implementation: viv
    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: 2025-12-02 UTC
    [21:28:52.292] weston 12.0.4
    https://wayland.freedesktop.org
    Bug reports to: ``https://gitlab.freedesktop.org/wayland/weston/issues/
    Build: 12.0.4
    [21:28:52.292] Command line: weston -Bdrm-backend.so --current-mode -Swayland-0 --use-g2d
    [21:28:52.292] OS: Linux, 5.15.148-6.7.0+git.bfdbfb2c85fb, #1-TorizonCore SMP PREEMPT Thu Jun 20 15:59:41 UTC 2024, aarch64
    [21:28:52.292] Flight recorder: enabled
    [21:28:52.292] Using config file ‘/etc/xdg/weston/weston.ini’
    [21:28:52.293] Output repaint window is 7 ms maximum.
    [21:28:52.293] Loading module ‘/usr/lib/aarch64-linux-gnu/libweston-12/drm-backend.so’
    [21:28:52.300] initializing drm backend
    [21:28:52.300] Trying libseat launcher…
    00:00:00.020 [INFO] [seatd/server.c:145] New client connected (pid: 29, uid: 1000, gid: 1000)
    00:00:00.020 [INFO] [seatd/seat.c:170] Added client 7 to seat0
    00:00:00.020 [INFO] [seatd/seat.c:480] Opened client 7 on seat0
    [21:28:52.301] [libseat/libseat.c:73] Seat opened with backend ‘seatd’
    [21:28:52.301] [libseat/backend/seatd.c:212] Enabling seat
    [21:28:52.301] libseat: session control granted
    [21:28:52.305] using /dev/dri/card0
    [21:28:52.305] DRM: supports atomic modesetting
    [21:28:52.305] DRM: does not support GBM modifiers
    [21:28:52.305] DRM: does not support async page flipping
    [21:28:52.305] DRM: supports picture aspect ratio
    [21:28:52.305] Loading module ‘/usr/lib/aarch64-linux-gnu/libweston-12/g2d-renderer.so’
    g2d_open: fail with status -7
    [21:28:52.318] g2d_open fail.
    [21:28:52.319] g2d_renderer_create faile.
    [21:28:52.319] failed to initialize g2d renderer
    00:00:00.038 [INFO] [seatd/seat.c:418] No clients on seat0 to activate
    00:00:00.038 [INFO] [seatd/seat.c:524] Closed client 7 on seat0
    00:00:00.038 [INFO] [seatd/seat.c:192] Removed client 7 from seat0
    00:00:00.040 [INFO] [seatd/client.c:471] Client disconnected
    00:00:00.097 [INFO] [seatd/seatd.c:218] seatd stopped
    Switching back to vt 1

    the socker is created at /tmp/1000-runtime-dir/wayland-0

6

Fixing Weston G2D and Qt5 Wayland Connection Issues

1. Correct Container Tag Usage

You’re absolutely right about the tag inconsistency. Since your device shows CT_TAG_WESTON=3, you should use the environment variable for consistency (1):

weston:
  image: torizon/weston-imx8:$CT_TAG_WESTON

For Qt5, check your available Qt5 tag with:

env | grep CT_TAG_QT5

2. Weston G2D Renderer Failure

The critical issue in your Weston logs is:

g2d_open: fail with status -7
g2d_renderer_create faile.
failed to initialize g2d renderer

This G2D renderer failure is causing Weston to crash, which explains why your Qt application can’t connect to the Wayland socket. The G2D renderer requires proper GPU access.

3. Wayland Socket Path Issue

Your Wayland socket is created at /tmp/1000-runtime-dir/wayland-0, but Qt applications typically look for /tmp/wayland-0. You need to set the correct environment variable:

mk3-debug:
  environment:
    - QT_QPA_PLATFORM=wayland
    - WAYLAND_DISPLAY=/tmp/1000-runtime-dir/wayland-0
    - XDG_RUNTIME_DIR=/tmp/1000-runtime-dir

4. Complete Working Docker Compose

Here’s the corrected configuration that should resolve both the G2D and Wayland connection issues (2):

services:
  mk3-debug:
    build:
      context: .
      dockerfile: Dockerfile.debug
    environment:
      - QT_QPA_PLATFORM=wayland
      - WAYLAND_DISPLAY=/tmp/1000-runtime-dir/wayland-0
      - XDG_RUNTIME_DIR=/tmp/1000-runtime-dir
      - ACCEPT_FSL_EULA=1
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /dev/dri
        target: /dev/dri
      - type: bind
        source: /dev/galcore
        target: /dev/galcore
    device_cgroup_rules:
      - "c 199:* rmw"  # galcore
      - "c 226:* rmw"  # dri
    depends_on:
      - weston

  weston:
    image: torizon/weston-imx8:$CT_TAG_WESTON
    environment:
      - ACCEPT_FSL_EULA=1
    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
    device_cgroup_rules:
      - "c 4:* rmw"
      - "c 253:* rmw"
      - "c 13:* rmw"
      - "c 226:* rmw"
      - "c 10:223 rmw"
      - "c 199:0 rmw"
    command: --developer

(2)

5. Alternative Solution if G2D Issues Persist

If the G2D renderer continues to fail, you can try running Weston without G2D acceleration by modifying the Weston configuration (3). However, the proper solution is ensuring GPU device access as shown above.

The key fixes are:

  1. Use environment variable tags for consistency
  2. Set correct Wayland socket path environment variables
  3. Ensure proper GPU device access for both Weston and Qt containers

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.