Wayland / Weston on torizon minimal image

I’m trying to build a wayland/weston based image based on the torizon-minimal.

Using torizon/integration.xml, I can use the following settings to add graphics support to our distro:

DISTRO_FEATURES_REMOVE:remove = "pulseaudio wayland opengl"
DISTRO_FEATURES:append = " pulseaudio wayland opengl"

Credits to: DISTRO_FEATURES:append After DISTRO_FEATURES:remove Has No Effect – Burkhard Stubert

When building the torizon-minimal recipe, I hit issues with westone/wayland groups and user.
I was able to workaround them by tweaking the following files:

Append this

weston:x:2000:
weston-launch:x:2001:
wayland:x:2002:

to: layers/meta-toradex-torizon/files/torizon-static-group

and this:

weston:x:2000:2000:Wayland Weston User:/var/lib/weston:/sbin/nologin

to: layers/meta-toradex-torizon/files/torizon-static-passwd

In this way ne build went passed this issue but this is clearly not a solution and having to fork your meta-layer for this seems a bit over-kill.

How do you suggest to proceed here?

@leo.tx @drew.tx

Hi, I’m the Toradex AI Assistant.

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


Recommended Approach: Use Containerized Weston

Based on Torizon’s architecture and best practices, the recommended approach for adding Wayland/Weston graphics support is to use the provided Weston containers rather than building Weston directly into the base image (1).

Why Containers Are Preferred

The default choice for Graphic User Interface (GUI) in Torizon is to use the Wayland protocol (1). Torizon provides a container with the Weston compositor and clear instructions about how to run it (1). This approach offers several advantages:

  • Separation of concerns: Graphics components run in isolated containers
  • Easier maintenance: No need to modify core system files
  • Better security: Container isolation
  • Simplified updates: Update graphics stack independently

Using the Provided Weston Container

Toradex provides pre-built Weston containers that you can use directly (2). Here’s how to set up a basic Weston container using Docker Compose:

services:  
  weston:  
    image: torizon/weston:4  
    # 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'  

(2)

GUI Framework Configuration

Many commonly used GUI-toolkits support Wayland as a rendering back end. Usually, you need to set an environment variable that configures rendering mode (1).

Toolkit Env setting
GTK3 GDK_BACKEND=“wayland”
Qt5 QT_QPA_PLATFORM=“wayland”
SDL2 SDL_VIDEODRIVER=“wayland”
(1)

Alternative: Custom Image Approach

If you absolutely need to build Weston into the base image, consider creating a custom recipe that properly handles the user/group requirements without modifying the core meta-layer files. However, this approach goes against Torizon’s container-first philosophy and may complicate future updates.

Next Steps

  1. Try the containerized approach first: Use the provided Weston containers
  2. Configure your application: Set appropriate environment variables for your GUI toolkit
  3. Test thoroughly: Ensure your application works correctly with the containerized Weston

This container-based approach aligns with Torizon’s design principles and eliminates the need to fork meta-layers or modify core system files.

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.

Hello @Giona,

I agree that forking the meta layers is indeed suboptimal.
Maybe another entry with his additional fragment can be added to this variable: https://github.com/torizon/meta-toradex-torizon/blob/868c9ac20ea68c0874a61068ac3978938256c1cc/conf/distro/include/base-distro.inc#L59
I have not tried this out myself and the assumption that another entry could be added is purely based on the fact that variable name is ending with the letter “s”.
In essence you would in that case simply append the file to that variable.

Best regards,
Collin