Visualize docker application on weston compositor running on Host

Technical Support
,
1

I am using torizon/wayland-base:3 as my container base image. Architecture of my container is aarch64 while my host is amd (x86_64). I would like to visualize my GUI based application (running inside container) on weston compositor running on the host.
Application on the docker runs fine without GUI

Weston version on the host: 9.0.0
on Container: 10.0.1

Have explicitly set wayland display: wayland-0 (same on the host and the container)
Docker have all the necessary permissions of the XDG_RUNTIME_DIR

What am i doing wrong?

2

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello!

To display your GUI application running inside a Docker container on the Weston compositor of your host, there are a few key areas to consider, especially given the differences in architecture and Weston versions.

  1. Wayland Socket Sharing: Ensure that the Wayland socket is correctly shared between the host and the container. This typically involves bind-mounting the Wayland socket from the host into the container. You can achieve this with a Docker run command like:

    docker run -v /run/user/1000/wayland-0:/run/user/1000/wayland-0 -e WAYLAND_DISPLAY=wayland-0 ...

    Make sure the XDG_RUNTIME_DIR is correctly set and accessible by the container.

  2. Permissions: Double-check that the container has the necessary permissions to access the display resources. This includes ensuring that the XDG_RUNTIME_DIR environment variable is set correctly and that the container has access to the necessary device files.

  3. Architecture Compatibility: Since your container is running on an aarch64 architecture while your host is x86_64, ensure that any binaries or libraries used by your application are compatible with the host architecture. This might require using a cross-compilation toolchain or ensuring that the application is architecture-independent.

  4. Troubleshooting: Check the logs of both the Weston compositor and your application for any errors or warnings that might indicate what is going wrong. You can access the logs using Docker’s logging capabilities:

    docker logs <container_id>

By focusing on these areas, you should be able to diagnose and resolve the issue with displaying your GUI application on the host’s Weston compositor.

If you have any more questions or need further assistance, feel free to ask!

Best regards,
Toradex AI Assistant.

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

How to display GUI in Torizon?.

3

Greetings @Zaid,

The 3 tag containers don’t have any x86/amd64 based containers. Our 4 tag containers do however have images in this architecture. I just ran the following command on my standard Ubuntu x86 machine and it worked:

docker container run -d --name=weston --net=host \
    --cap-add CAP_SYS_TTY_CONFIG -v /dev:/dev -v /tmp:/tmp \
    -v /run/udev/:/run/udev/ --device-cgroup-rule="c 4:* rmw" \
    --device-cgroup-rule="c 13:* rmw" --device-cgroup-rule="c 226:* rmw" \
    --device-cgroup-rule="c 10:223 rmw" \
    torizon/weston:4 \
    --developer

With this Weston was running on my Ubuntu machine. If you are running something else other than Ubuntu though you may need to try it for yourself.

Best Regards,
Jeremias

4

Regardless of whether weston runs on the host computer, this run commands launches a weston compositor. Being new to torizon i might have some basic confusions but below mentioned is what i am lookinf for

I have an executable build for embeded device. Now instead of running on the device, i want to contanerize the application with torizon and the visualization with weston inside the container.

Application i am able to run inside docker and would like to have the GUI on my host weston compositor.

On both the host and inside container
$WAYLAND_DISPLAY = wayland-0
$XDG_RUNTIME_DIR = /run/user/1000
$QT_QPA_PLATFORM = wayland

Output of wayland-info

interface: ‘wl_compositor’, version: 5, name: 1
interface: ‘wl_drm’, version: 2, name: 2
interface: ‘wl_shm’, version: 1, name: 3
formats (fourcc):
0x48344258 = ‘XB4H’
0x48344241 = ‘AB4H’
0x48345258 = ‘XR4H’
0x48345241 = ‘AR4H’
0x30334258 = ‘XB30’
0x30334241 = ‘AB30’
0x30335258 = ‘XR30’
0x30335241 = ‘AR30’
0x36314752 = ‘RG16’
0x34324258 = ‘XB24’
0x34324241 = ‘AB24’
1 = ‘XR24’
0 = ‘AR24’
interface: ‘wl_output’, version: 3, name: 4
x: 0, y: 0, scale: 1,
physical_width: 0 mm, physical_height: 0 mm,
make: ‘unknown’, model: ‘unknown’,
subpixel_orientation: unknown, output_transform: normal,
mode:
width: 1920 px, height: 1080 px, refresh: 60.000 Hz,
flags: current preferred
interface: ‘zxdg_output_manager_v1’, version: 3, name: 5
xdg_output_v1
output: 4
name: ‘Virtual-1’
description: ‘Unknown Display’
logical_x: 0, logical_y: 0
logical_width: 1920, logical_height: 1080
interface: ‘wl_data_device_manager’, version: 3, name: 6
interface: ‘zwp_primary_selection_device_manager_v1’, version: 1, name: 7
interface: ‘gtk_primary_selection_device_manager’, version: 1, name: 8
interface: ‘wl_subcompositor’, version: 1, name: 9
interface: ‘xdg_wm_base’, version: 4, name: 10
interface: ‘zxdg_shell_v6’, version: 1, name: 11
interface: ‘gtk_shell1’, version: 5, name: 12
interface: ‘wp_viewporter’, version: 1, name: 13
interface: ‘zwp_pointer_gestures_v1’, version: 3, name: 14
interface: ‘zwp_tablet_manager_v2’, version: 1, name: 15
interface: ‘wl_seat’, version: 5, name: 16
name: seat0
capabilities: pointer keyboard
keyboard repeat rate: 33
keyboard repeat delay: 500
interface: ‘zwp_relative_pointer_manager_v1’, version: 1, name: 17
interface: ‘zwp_pointer_constraints_v1’, version: 1, name: 18
interface: ‘zxdg_exporter_v1’, version: 1, name: 19
interface: ‘zxdg_importer_v1’, version: 1, name: 20
interface: ‘zwp_linux_dmabuf_v1’, version: 4, name: 21
main device: 0xE280
tranche
target device: 0xE280
flags: none
formats (fourcc) and modifiers (names):
0x34325241 = ‘AR24’; 0x00ffffffffffffff = INVALID_MODIFIER
0x34324241 = ‘AB24’; 0x00ffffffffffffff = INVALID_MODIFIER
0x34325258 = ‘XR24’; 0x00ffffffffffffff = INVALID_MODIFIER
0x30334241 = ‘AB30’; 0x00ffffffffffffff = INVALID_MODIFIER
0x36314752 = ‘RG16’; 0x00ffffffffffffff = INVALID_MODIFIER
0x48344241 = ‘AB4H’; 0x00ffffffffffffff = INVALID_MODIFIER
interface: ‘zwp_keyboard_shortcuts_inhibit_manager_v1’, version: 1, name: 22
interface: ‘zwp_text_input_manager_v3’, version: 1, name: 23
interface: ‘wp_presentation’, version: 1, name: 24
presentation clock id: 1 (CLOCK_MONOTONIC)
interface: ‘xdg_activation_v1’,

But somehow still i am unable to visualize the GUI on host weston

Below is my docker run

sudo docker run --privileged -it --device /dev/dri --device /dev/input --name=torizon_container --platform=linux/arm64 -e DISPLAY=$DISPLAY -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY -e XDG_RUNTIME_DIR=/run/user/1000 -v /tmp/.X11-unix:/tmp/.X11-unix -v /run/user/1000:/run/user/1000 -v /dev:/dev -v /sys:/sys -v /proc:/proc -v /home/zaid/sceniq_rootfs/:/sceniq_rootfs torizon_sceniq

5

Oh I see, you want to use the Weston that is already running on your development PC. I thought you wanted to run Weston on your PC (i.e via a container).

Well this is probably more difficult. First of all is your GUI application even being compiled in the X86 architecture? It looks like you’re just trying to run the arm64 based application container on your X86 machine with your X86 Weston.

Also if you want to just run your GUI application on your development PC’s Weston. Have you tried just running the executable, rather than trying to run the entire container image containing the executable?

My reasoning is that the application containers are designed and intended to run on our Torizon OS systems in the end, so trying to adapt it for another system may be complicated. This is compared to just running the executable itself. Which brings up another question, is the GUI executable giving any errors when you try to run it on your development PC?

I also forgot to ask at the start. Is there a reason you’re trying to run your GUI application like this on your host development PC?

Best Regards,
Jeremias

6

My executable is specifically compiled for aarch64 architecture. My embeded device OS is actually based on torizon OS with some modifications.

Now i want to exclude my embeded device out of the equation and contanerize my application for the sake of it being portable. My embeded device use weston compositor for visualization.

Executable runs fine inside the container, i think it also recognize the wayland socket, its just that i am unable to visualize my UI on weston compositir running on the host

If the approach can be better, please do suggest something. In the end its all about weston and torizon

7

Okay wait, let’s back up and could you describe your setup to me, because it seems like some details are not being fully explained.

It sounds like you have some non-Toradex x86 embedded device, that is running some custom “Torizon OS-like” OS. Your custom OS has Weston running on the host as well. Is that more or less correct? Any other details?

Best Regards,
Jeremias

8

This is my base image for the embeded device

I have just started working on the project so apparently i was wrong about a custom torizon OS.

On the device: executable works fine on weston compositor running on the host( host is embeded device)

Now, taking device out of the equation, i want to run executable inside torizon container (linux/aarch64), with weston running on the host (my local pc: amd64) or inside the container itself( independent of amd64).

For path and library dependencies issue, i have mounted rootfs of emebded device inside my container
Executable run perfect, just unable to visualize UI

9

So you’re not running Torizon OS at all then? And what is this embedded device you are using? Is it even a Toradex embedded device?

Apologies, but your system setup differs quite a lot from our standard Toradex setup. I’m not even sure how we can investigate or even try to test something when we are unfamiliar with your setup.

Best Regards,
Jeremias