version: "2.5"
services:
weston:
image: torizon/weston-vivante:2
# Accept the EULA required to run imx8 vivante graphic drivers
network_mode: host
environment:
- ACCEPT_FSL_EULA=1
# Required to get udev events from host udevd via netlink
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 tty1
- 'c 4:1 rmw'
# ... for /dev/input devices
- 'c 13:* rmw'
- 'c 199:* rmw'
# ... for /dev/dri devices
- 'c 226:* rmw'
command: --developer
app:
image: company/app:latest
depends_on:
- weston
environment:
- ACCEPT_FSL_EULA=1 # for Weston
volumes:
- /tmp:/tmp
- /dev/dri:/dev/dri # for Weston
- /dev/galcore:/dev/galcore # for Weston
- /sys/class/backlight/backlight/brightness:/root/brightness # for screen
- /var/run/dbus:/var/run/dbus # for wifi
devices:
- /dev/ttyLP2 # for serial
device_cgroup_rules:
- 'c 199:* rmw' # for weston
- 'c 226:* rmw' # for weston
It works great since many time, but I tried to install this stack on a new board with easy installer, pair with torizon.io and push package OS and docker-compose.
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
The error message atomic: couldn't commit new state: Permission denied and repaint-flush failed: Permission denied suggests that there might be a permissions issue related to the DRM (Direct Rendering Manager) devices or other related resources.
Here are a few steps you can take to troubleshoot and potentially resolve this issue:
Check Device Permissions:
Ensure that the necessary device permissions are correctly set in your docker-compose.yml file. You have already added device cgroup rules for /dev/dri and /dev/galcore, but double-check that these devices exist and have the correct permissions on the new board.
Verify Weston Configuration:
Make sure that the weston.ini configuration file is correctly set up and accessible. If you are using a custom weston.ini, ensure it is correctly bind-mounted or included in the Weston container.
Check Kernel and Driver Compatibility:
Ensure that the kernel version and the graphics drivers on the new board are compatible with the Weston version you are using. Sometimes, differences in kernel versions or driver updates can cause permission issues.
Udev Rules:
Verify that the udev rules are correctly set up and applied. You can try reloading the udev rules and restarting the udev service:
sudo udevadm control --reload-rules
sudo systemctl restart udev
Run Weston with Elevated Privileges:
As a temporary measure, you can try running the Weston container with elevated privileges to see if it resolves the issue. Add the privileged: true flag to the Weston service in your docker-compose.yml:
I redo the procedure on same device, same issue. I use an other device, issue disappear. Therefore, issue seems appears on only one devise. I don’t investigate more and close the ticket.
Sorry I could not help you because I could not reproduce this behavior.
But I have some things to note.
The tag you are using on torizon/weston-vivante:2 is supposed to be for Torizon OS 5 users, Torizon OS 6 users should use torizon/weston-vivante:3.
For production is usually a best practice to canonicalize the composer using the container hash that way you can make sure it is always the same image running on your app, the tag 2 is actually the latest major version 2 of this container and it is overwritten at each release.
