I would like developing a TorizonOS on Verdin iMX8M-Plus where the only UI to the user is a bash window on the HDMI screen where the user can see messages and interact with a keyboard.
Which is the supposed way to do this?
Should I need a docker-compose.yml with weston + something else?
Hi, I’m the Toradex AI Assistant.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
I’d be glad to help! To provide the most accurate guidance for creating a bash terminal interface on your HDMI display, could you let me know which version of Torizon OS you are running?
For reference, you can get detailed system information using the tdx-info command on your device. You can find more details about this tool at: Getting Device Information with Tdx-Info | Toradex Developer Center
Common platforms to mention:
Once I know your specific Torizon OS version, I can provide detailed guidance on the best approach for implementing a bash terminal interface on your HDMI display, including the appropriate docker-compose.yml configuration.
Best regards, Toradex AI Assistant.
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Hi @vix!
You could use the Weston terminal for it, as described here.
Please check if this fulfills your requirements.
Best regards.
Thanks.
I need one more clarification, because I’m not sure I understood the concept:
AFAI, this is the general concept. @ToradexAI , @lucas_az.tx correct?
When my application is the shell, I can use/open the weston-terminal directly in the weston container. But in any case, if I would open weston-terminal in another wayland (not weston) container it works (but much more complicated).
@ToradexAI , @lucas_az.tx correct?
Your understanding of the concept is correct! Let me clarify the architecture for you:
Weston as Window Manager/Compositor: Yes, Weston is the Wayland compositor (window manager) that runs in its own container and provides the graphical desktop environment (1). It’s essentially your “empty desktop” that manages the display output.
Client Applications: Applications that need to display graphics communicate with the Weston compositor through Wayland protocol. These can run in separate containers and connect to Weston via shared Unix sockets (1).
You can run weston-terminal directly within the Weston container using (1):
# docker exec weston weston-terminal
This is the simplest approach for your use case since you just need a bash terminal interface.
You’re also correct that you could run terminal applications in separate Wayland client containers. The Weston container creates Unix socket files (typically in /tmp/1000-runtime-dir) that allow graphical client applications to communicate with it (1). By bind mounting /tmp into a second container, a Wayland client application can access the Wayland compositor regardless of being in separate containers (1).
For a simple bash terminal interface on HDMI, using weston-terminal directly in the Weston container is the most straightforward approach. You would:
weston-terminal within that containerThis gives you exactly what you described: a bash window where users can see messages and interact with a keyboard.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
@ToradexAI can you give me an example of a docker-compose.yml that uses both a weston server and a wayland-base-imx8 container (for a client app)?
I can provide you with an example docker-compose.yml that demonstrates running both a Weston server and a client application. Here’s a configuration for iMX8 platforms:
services:
weston:
image: torizon/weston-imx8:4
# EULA required to run imx8 vivante graphic drivers
# Pre-accept as we ask the user accept the EULA already.
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'
# ... for /dev/dri devices
- 'c 226:* rmw'
# ... for /dev/galcore device
- 'c 199:0 rmw'
# ... for /dev/dma_heap device
- 'c 253:* rmw'
Shared Communication: The Weston container creates a Unix socket file so graphical client applications can communicate with it (typically in the /tmp/1000-runtime-dir directory) (1). By bind mounting /tmp into a second container, a Wayland client application can access the Wayland compositor regardless of being in separate containers (1).
Client Application Setup: For your client application container, you would need to:
/tmp to share the Wayland socketYou can start both services with (1):
# docker-compose -f <your-docker-compose-file> up
Note: For your specific client application container, you’ll need to add a second service definition that includes the wayland-base-imx8 image and your specific application requirements, ensuring it has access to the shared /tmp directory for Wayland communication.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
@ToradexAI I cannot see the container for a demo clietn app in the docker-compose.yml you suggested.
You’re absolutely right! I only provided the Weston service configuration. Here’s a complete docker-compose.yml example that includes both the Weston server and a client application container:
services:
weston:
image: torizon/weston-imx8:4
# EULA required to run imx8 vivante graphic drivers
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'
# ... for /dev/dri devices
- 'c 226:* rmw'
# ... for /dev/galcore device
- 'c 199:0 rmw'
# ... for /dev/dma_heap device
- 'c 253:* rmw'
client-app:
image: torizon/wayland-base-imx8:4
environment:
- ACCEPT_FSL_EULA=1
depends_on:
- weston
volumes:
- type: bind
source: /tmp
target: /tmp
command: /bin/bash -c "sleep 5 && weston-terminal"
Shared Communication: By bind mounting /tmp into both containers, the client application can access the Wayland compositor through the Unix socket file that Weston creates (typically in the /tmp/1000-runtime-dir directory) (1).
Service Dependencies: The depends_on ensures that Weston starts before the client application (1).
Client Application: In this example, the client container runs weston-terminal as a demonstration. You can replace this with your own bash-based application or terminal interface.
For your specific use case of having just a bash window, you could modify the client-app command to run your custom bash script or application that provides the user interface you need.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.