How to run app in two displays

matti.paksula · September 23, 2024, 8:22am

setup:

weston container

app1 container
app2 container

can not get app2 to draw on weston

ToradexAI · September 23, 2024, 8:22am

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

Did you like my answer?

To run applications on two displays using Weston on Torizon, you need to ensure that each application is directed to the correct display. Here’s a step-by-step guide to achieve this setup:

Prerequisites

Weston Container: Ensure you have the Weston container running.
App1 Container: Your first application container.
App2 Container: Your second application container.

Steps to Configure Multi-Display Setup

Identify the App IDs:
Each Wayland application can set an app ID. You need to find out the app ID for each of your applications. You can do this by running the application with the WAYLAND_DEBUG environment variable set.
```
WAYLAND_DEBUG=1 ./your-application
```
Look for the set_app_id request in the output. For example, you might see something like:
```
[123456.789]  -> wl_surface@4.set_app_id("app1")
```
Here, app1 is the app ID.
Configure weston.ini:
Edit the weston.ini file to specify which display each application should use. Here’s an example configuration:
```
[core]
shell=kiosk-shell.so

[output]
name=HDMI-A-1
mode=1920x1080

[output]
name=HDMI-A-2
mode=1920x1080

[kiosk-shell]
app-id=app1
output=HDMI-A-1

[kiosk-shell]
app-id=app2
output=HDMI-A-2
```
In this example:
- HDMI-A-1 and HDMI-A-2 are the names of the displays.
- app1 and app2 are the app IDs for your applications.
- Each [kiosk-shell] section directs an application to a specific display.
Run the Weston Container:
Ensure the Weston container is running with the updated weston.ini file. You can bind mount the weston.ini file if you are in the prototyping phase:
```
docker run -d --rm --name=weston --net=host -v /path/to/your/weston.ini:/etc/xdg/weston/weston.ini torizon/wayland-weston
```

Run Your Application Containers:
Start your application containers, ensuring they are set to use Wayland and have the correct app ID.

docker run -d --rm --name=app1 --net=host -e WAYLAND_DISPLAY=wayland-0 -e WAYLAND_DEBUG=1 your-app1-image
docker run -d --rm --name=app2 --net=host -e WAYLAND_DISPLAY=wayland-0 -e WAYLAND_DEBUG=1 your-app2-image

Troubleshooting

Check App IDs: Ensure the app IDs in the weston.ini file match those set by your applications.
Display Names: Verify the display names (e.g., HDMI-A-1, HDMI-A-2) using weston-info inside the Weston container.
Logs: Check the logs of the Weston container and your application containers for any errors or warnings.

By following these steps, you should be able to run app1 on one display and app2 on another display using Weston on Torizon.

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

HDMI enable for Colibri IMX8X.

sebastian-verge · September 23, 2024, 8:50am

Here are our app ids:

torizon@verdin-imx8mp-15207741:~$ docker compose run --rm -e WAYLAND_DEBUG=1 infotainment 2>&1 | grep set_app_id
[3625339.789]  -> xdg_toplevel@24.set_app_id("StarOSApp")
^C
torizon@verdin-imx8mp-15207741:~$ docker compose run --rm -e WAYLAND_DEBUG=1 dash 2>&1 | grep set_app_id
[3645913.156]  -> xdg_toplevel@24.set_app_id("StarDashApp")

Here is our weston.ini

[core]
idle-time=0
require-input=false
xwayland=true
modules=screen-share.so
shell=kiosk-shell.so
#require-outputs=all-found

[shell]
panel-position=top
locking=false
allow-zap=true
num-workspaces=1

[output]
name=HDMI-A-2
mode=preferred
app-ids=StarDashApp

[output]
name=HDMI-A-1
mode=preferred
app-ids=StarOSApp

Both screens show as connected:

torizon@verdin-imx8mp-15207741:~$ cat /sys/class/drm/card0-HDMI-A-1/status 
connected
torizon@verdin-imx8mp-15207741:~$ cat /sys/class/drm/card0-HDMI-A-2/status 
connected

Here is the screen setup from the weston-info call:

interface: 'zxdg_output_manager_v1', version: 2, name: 4
        xdg_output_v1
                output: 22
                name: 'HDMI-A-2'
                logical_x: 1920, logical_y: 0
                logical_width: 1920, logical_height: 1080
        xdg_output_v1
                output: 21
                name: 'HDMI-A-1'
                logical_x: 0, logical_y: 0
                logical_width: 1920, logical_height: 1080

We can run each container on its own but if we run them at the same time, we just get a 139 exit code:

torizon@verdin-imx8mp-15207741:~$ docker stats --no-stream
CONTAINER ID   NAME                  CPU %     MEM USAGE / LIMIT     MEM %     NET I/O       BLOCK I/O        PIDS
3a0b29ca1608   live-infotainment-1   44.68%    111MiB / 7.754GiB     1.40%     3.43kB / 0B   0B / 61.4kB      9
7e96d7a3546c   live-weston-1         16.12%    18.26MiB / 7.754GiB   0.23%     0B / 0B       32.8kB / 307kB   11
torizon@verdin-imx8mp-15207741:~$ docker compose up dash --no-deps
[+] Running 1/1
 ✔ dash Pulled    0.7s
[+] Running 1/0
 ✔ Container live-dash-1  Created    0.0s
Attaching to live-dash-1
live-dash-1  | Loaded language: "en"
live-dash-1  | Font "Inter-Bold.ttf" loaded
live-dash-1  | Font "Inter-Medium.ttf" loaded
live-dash-1  | Font "Inter-Regular.ttf" loaded
live-dash-1  | Font "Inter-SemiBold.ttf" loaded
live-dash-1 exited with code 139

henrique.tx · September 23, 2024, 6:41pm

Hi @sebastian-verge !

Have you tried following the Working with Weston on Torizon OS | Toradex Developer Center? Specifically the Multi-Display section.

I just tried the Single-DRM approach listed there and it worked for me.

Just one catch: the weston.ini of the torizon-samples repository did a small mistake where the the app-ids is repeated. For that specific demo, you need to replace org.qt-project.animation with capp on one of the outputs. I just submitted a PR to fix it. Here it is for your reference: Fix app-ids to display the tic-tac-toe app by griloHBG · Pull Request #32 · toradex/torizon-samples · GitHub

As I tested on dual HDMI, I also had to modify the output names (just like you did. you know the drill )

For reference, here is my setup:

Hardware

Verdin iMX8MP Q 4GB WB IT V1.1A
Verdin Development Board V1.1A
- with Verdin DSI to HDMI Adapter Rev. 1.1
An HDMI to USB capture card connected to the DSI to HDMI Adapter
A 4k LG monitor connected to X37 (the native HDMI)

Software

Torizon OS 6.7.0-build.18
Multi-Display Torizon sample for single-DRM - bookworm branch (torizon-samples/multi-display/single-drm-interface at bookworm · toradex/torizon-samples · GitHub)
OBS on my host notebook to visualize the HDMI output from the module (or any other software that allows me to see it on my notebook).

Result

See the photo below with the result: tic-tac-toe on the left (capp - 4k LG monitor - native HDMI from) and the Qt app (org.qt-project.animation - OBS running on my notebook - HDMI to DSI adapter).

Please let us know if this helps you

Best regards,

sebastian-verge · September 24, 2024, 4:35pm

Hi @henrique.tx!
Thank you for the reply!

I can get the demo app working, and I can move the app around the outputs. With our apps on the other hand, I cannot move the app around:

With the demo app I can move the output around

[output]
name=HDMI-A-2
app-ids=StarDashApp,org.qt-project.animation

[output]
name=HDMI-A-1
app-ids=StarOSApp,capp

[output]
name=HDMI-A-2
app-ids=StarOSApp,capp

[output]
name=HDMI-A-1
app-ids=StarDashApp,org.qt-project.animation

With our dashboard app I can not move the output around

[output]
name=HDMI-A-2
app-ids=StarDashApp,org.qt-project.animation

[output]
name=HDMI-A-1
app-ids=StarOSApp,capp

[output]
name=HDMI-A-2
app-ids=StarOSApp,capp

[output]
name=HDMI-A-1
app-ids=StarDashApp,org.qt-project.animation

I posted the app id output (I found that using the command from the dock you referenced) which in our case is:

[2604330.484]  -> xdg_toplevel@24.set_app_id("StarDashApp")

The only difference between the two docker compose files I have are:

Can you suggest where I should start looking next?

Thanks,
Seb

henrique.tx · September 24, 2024, 9:52pm

Hi @sebastian-verge !

Thanks for testing the demo and for the additional information.

Is it possible that your Qt app is simply “forcing” its way to one of the outputs?

I don’t even know if this is possible, but I know that using Qt you can quite some flexibility to define some behaviors in your application.

Maybe you can enable and check the debug log of your applications as well as check the logs from Weston by enabling the WAYLAND_DEBUG environment variable.

My line of thought: since the demo is working as expected for you, there might be something specific to your application that is “breaking” the desired behavior.

One other thing you could try: write a very simple hello-world GUI application using Qt (as simple as possible like some colored background with a button in the middle) and try to put it on each of the displays. You can do one with e.g. blue background and the other red, so you know which is which. This simple test might give you some clue about what is going on with your application.

Best regards,

sebastian-verge · September 27, 2024, 11:28am

Hi @henrique.tx,

I have managed to get a little further, but I have hit a little bit of a wall again

So, the first, the things that worked!

It turns out that having the app render in full screen was messing with the screen placements, once we disabled that we were able to move the apps to different outputs!
We have used the tic-tac-toe app as a baseline app to run at the same time as our apps, and we have managed to make them both work while another app is running:

App 1 (Output 1) + Tic Tac Toe (Output 2)

App 2 (Output 2) + Tic Tac Toe (Output 1)

One thing I have also noticed is that you can have all your apps on the same screen, they just cover each other.

Here is our current `weston.ini` file:

[core]
idle-time=0
require-input=false
xwayland=true
shell=kiosk-shell.so

[shell]
background-image=/bg.png
background-color=0xFF00FF00
panel-color=0xFF00FF00
panel-position=none
locking=false
allow-zap=true
num-workspaces=1

[output]
name=HDMI-A-1
mode=preferred
app-ids=StarDashApp,capp

[output]
name=HDMI-A-2
mode=preferred
transform=rotate-90
app-ids=StarOSApp

Secondly, the further questions I have:

Can you see what I am doing wrong with regards to background-color and background-image, it’d be great if we could get our branding working in kiosk mode!
I am at a loss in regards to what to do next to debug the Exit code 139 (which is usually a SIGSEGV).

We have run the second app with WAYLAND_DEBUG=1, and QT_DEBUG_PLUGINS=1 but everything seems normal there. (I can email that to you if it helps?)

Many thanks,
Seb

henrique.tx · September 27, 2024, 4:09pm

Hi @sebastian-verge !

Great news!

So guessed correctly! It is nice to shoot some correct guess from time to time hahaha

~~Just to be sure here: the “App 1 (Output 1) + Tic Tac Toe (Output 2)” picture shows the Output 1 (with App 1) completely black… Is that working correctly?~~

~~If yes, then nice!~~

EDIT: oh… ok… this is related to the 139 segfault, right? please ignore

Now to the open points:

kiosk-shell vs background-image

My first guess would be that maybe the weston.ini being picked up could be the developer one (Working with Weston on Torizon OS | Toradex Developer Center) instead of yours. But since you are playing around with the position of the applications and it is working well, this must not be the case.

After some trial and error from my side (which started to drive me crazy ), I realized that the culprit was the shell=kioski-shell.so. I simply commented it out and I could get my background-image working .

Could you please try on your side?

Disclaimer: I know that in order to use app-ids, kiosk-shell is needed (reference: weston.ini(5) — Arch manual pages). So since I guess that having the applications on their correct display is more important than the background image… seems like there is not much to do besides simply do not use background-image .

Regarding the background-color, it is working as expected on my side. Your weston.ini is using background-color=0xFF00FF00, which is the green color. It is showing green for me.

Side note: using 0xFF00FF00 or 0x0000FF00 has the same outcome, so the alpha (since the hexa means 0xAARRGGBB) is not doing much. 0x00FF00 gives the same result, so 0xAARRGGBB seems not to be mandatory (weston.ini(5) — Arch manual pages).

Segfault

This is from your own application/container live-dash-1, right?

sebastian-verge:

torizon@verdin-imx8mp-15207741:~$ docker compose up dash --no-deps
[+] Running 1/1
 ✔ dash Pulled    0.7s
[+] Running 1/0
 ✔ Container live-dash-1  Created    0.0s
Attaching to live-dash-1
live-dash-1  | Loaded language: "en"
live-dash-1  | Font "Inter-Bold.ttf" loaded
live-dash-1  | Font "Inter-Medium.ttf" loaded
live-dash-1  | Font "Inter-Regular.ttf" loaded
live-dash-1  | Font "Inter-SemiBold.ttf" loaded
live-dash-1 exited with code 139

This one is hard for me to help. This could be caused by so many issues related to the application… My recommendation is to debug it. Also, just being paranoid, you can check the the dependencies for your application are all there and are in the expected version.

Best regards,

henrique.tx · October 9, 2024, 3:37pm

Hi @matti.paksula and @sebastian-verge !

Do you have any update here?

Were you able to make any progress?

Best regards,

sebastian-verge · October 22, 2024, 11:38am

Hi @henrique.tx

Sorry for the slower reply!

We did have some success, it seems that simply delaying the startup of the second application (by around 15 seconds) stopped the seg fault in its tracks…

We have made a simple ‘hello world’ app pair that displays on both screens and does not have the segfault issue implying its something in the application itself.

The code for that is here if anyone is interested: GitHub - vergemotorcycles/hello-world

This is obviously not quite the solution we were hoping for, but it’s the best we currently have! We are going to return to try to work out why this happens later.

Thank you for your help

henrique.tx · October 22, 2024, 1:03pm

Hi @sebastian-verge !

Thanks for sharing your approach!

Hopefully it will help others in the same situation

I will mark your message as the solution.

Best regards,