How to set a PySide2 application to autorun on Weston (Torizon OS, i.MX7)?

Coders · April 2, 2026, 4:08am

I am using an i.MX7 with Torizon OS (ARMv7), and I am running my application on it.
I have already deployed a project on Torizon Cloud to run Weston in the background. That setup is working fine. On top of Weston, I want to run a PySide2 application.
I tried using a systemd service to start my application automatically on Weston. The application starts successfully, but the touch input does not work.
Below is my app.service file:
torizon@colibri-imx7-emmc-06673340:~$ cat /etc/systemd/system/app.service

[Unit]
Description=Octo App (Wayland Client)
After=docker.service systemd-udevd.service
Requires=docker.service

[Service]
WorkingDirectory=/home/torizon/

Wait for Wayland

ExecStartPre=/bin/bash -c ‘until [ -e /tmp/1000-runtime-dir/wayland-0 ]; do sleep 1; done’

Wait for input subsystem

ExecStartPre=/bin/bash -c ‘until [ -d /dev/input ]; do sleep 1; done’
ExecStartPre=/bin/bash -c ‘until ls /dev/input/event* >/dev/null 2>&1; do sleep 1; done’

Wait for udev (VERY IMPORTANT)

ExecStartPre=/bin/bash -c ‘udevadm settle’

Small delay for stability

ExecStartPre=/bin/sleep 2

Run docker properly

ExecStart=/usr/bin/docker compose up
ExecStop=/usr/bin/docker compose down

Restart=always

User=torizon

[Install]
WantedBy=multi-user.target

also check my docker-compose.yml
services:
app:
image: intersense123/octo:1
privileged: true
depends_on:
- weston
environment:
- QT_QPA_PLATFORM=wayland
- XDG_RUNTIME_DIR=/tmp/1000-runtime-dir
- QT_QPA_GENERIC_PLUGINS=evdevtouch
- QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS=/dev/input/event0
- QT_WAYLAND_DISABLE_WINDOWDECORATION=1
cap_add:
- SYS_TIME
- NET_ADMIN
- SYS_BOOT
volumes:
- /tmp:/tmp
- /tmp/1000-runtime-dir:/tmp/1000-runtime-dir
- /dev:/dev
- /media:/media
- /sys:/sys
- /etc/machine-id:/etc/machine-id:ro
- /etc/localtime:/etc/localtime:ro
- /etc/timezone:/etc/timezone:ro
- /var/run/systemd:/var/run/systemd
- /run/dbus:/run/dbus
- /run/udev:/run/udev
- /home/torizon/Precigo/precigo.db:/home/torizon/app/precigo.db
- /home/torizon/Precigo/OctoPreciGo.db:/home/torizon/app/OctoPreciGo.db
- /home/torizon/Precigo/Octo_CSV:/home/torizon/app/Octo_CSV
devices:
- /dev/ttymxc0
- /dev/rtc0
- /dev/rtc1
network_mode: host

If i run using docker-compose up it runs perfect and touch also works but sometime touch not works.
My goal is:

Run the PySide2 application on Weston
Enable autorun at boot
Ensure touch input works correctly
Could someone guide me on how to properly configure this setup or what might be causing the touch issue?

ToradexAI · April 2, 2026, 4:09am

Hi, I’m the Toradex AI Assistant.

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

Autorun Configuration for PySide2 Application on Torizon OS

For autorunning applications on Torizon OS, the recommended approach is to use the docker-compose systemd service with a docker-compose.yml file placed in /var/sota/storage/docker-compose/ (1).

Recommended Autorun Setup

Instead of creating a custom systemd service, use the built-in docker-compose service by placing your docker-compose.yml file in the correct location (1):

sudo mkdir -p /var/sota/storage/docker-compose
sudo cp docker-compose.yml /var/sota/storage/docker-compose/

Container Configuration Improvements

Your docker-compose configuration needs some adjustments for proper hardware access. For i.MX7, use these device cgroup rules (2):

services:
  weston:
    image: torizon/weston:4
    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
    device_cgroup_rules:
      - 'c 4:0 rmw'
      - 'c 4:7 rmw'
      - 'c 13:* rmw'
      - 'c 226:* rmw'
      - 'c 10:223 rmw'

Environment Variables for GUI Applications

For your PySide2 application, ensure you have the correct Wayland environment variables set (3):

QT_QPA_PLATFORM: Set to “wayland” for Qt applications
WAYLAND_DISPLAY: Typically “wayland-0”
XDG_RUNTIME_DIR: Should match between containers

Touch Input Configuration

For touch input issues, consider using the touch2pointer application if your PySide2 app doesn’t handle touch events directly (4). This converts touch events to pointer events for applications that aren’t touch-aware.

Container Restart Behavior

Use the restart parameter in your docker-compose.yml to control container behavior (1):

services:
  app:
    restart: unless-stopped

The available restart options are (1):

no: Do not automatically restart (default)
on-failure: Restart if exits with error
always: Always restart if stopped
unless-stopped: Similar to always, but not after manual stop

Production Deployment

For production, consider using TorizonCore Builder Tool to pre-provision your containers into a custom Torizon OS image (1).

To troubleshoot touch issues, check if your application properly handles Wayland touch events or if you need to implement touch2pointer as an intermediate solution.

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.

Coders · April 2, 2026, 5:03am

sudo mkdir -p /var/sota/storage/docker-compose
sudo cp docker-compose.yml /var/sota/storage/docker-compose/

after doing above steps what next step do i follow also i create docker-compose attched with weston and run successfully mannual using docker-compose.yml up runs successfully so do i prefer system service or above step you menstioned @ToradexAI
below is structured working docker-compose.yml
services:
weston:
image: torizon/weston:stable-rc
restart: always
privileged: true
environment:
- XDG_RUNTIME_DIR=/run/user/1000
volumes:
- /tmp:/tmp
- /dev:/dev
- /run/udev:/run/udev
- /run/user/1000:/run/user/1000
app:
image: intersense123/octo:1
privileged: true
restart: always
depends_on:
- weston
environment:
- QT_QPA_PLATFORM=wayland
- WAYLAND_DISPLAY=wayland-0
- XDG_RUNTIME_DIR=/run/user/1000
cap_add:
- SYS_TIME
- NET_ADMIN
- SYS_BOOT
volumes:
- /tmp:/tmp
- /dev:/dev
- /media:/media
- /sys:/sys
- /etc/machine-id:/etc/machine-id:ro
- /etc/localtime:/etc/localtime:ro
- /etc/timezone:/etc/timezone:ro
- /var/run/systemd:/var/run/systemd
- /run/dbus:/run/dbus
- /run/udev:/run/udev
- /run/user/1000:/run/user/1000
- /home/torizon/Precigo/precigo.db:/home/torizon/app/precigo.db
- /home/torizon/Precigo/OctoPreciGo.db:/home/torizon/app/OctoPreciGo.db
- /home/torizon/Precigo/Octo_CSV:/home/torizon/app/Octo_CSV
devices:
- /dev/ttymxc0
- /dev/rtc0
- /dev/rtc1
network_mode: host

ToradexAI · April 2, 2026, 5:04am

Next Steps for Autorun Configuration

Perfect! You’ve placed the docker-compose.yml file in the correct location. Now you should disable your custom systemd service and use the built-in Torizon OS docker-compose service instead(1).

Remove Your Custom Service

First, stop and disable your custom app.service:

sudo systemctl stop app.service
sudo systemctl disable app.service

Enable the Built-in Docker-Compose Service

Torizon OS has a systemd service called docker-compose that automatically starts containers from /var/sota/storage/docker-compose/docker-compose.yml at boot(1). This is the preferred method for autorunning containers on Torizon OS(1).

To enable this service:

sudo systemctl enable docker-compose.service
sudo systemctl start docker-compose.service

Verify the Setup

Check that your containers are running:

docker ps

You should see both your Weston and application containers running.

Configuration Improvements

Your docker-compose.yml looks good, but consider these refinements for i.MX7:

Use specific Weston image: Replace torizon/weston:stable-rc with torizon/weston:4 for better stability(2)
Add device cgroup rules instead of privileged: true for better security(2):

weston:
  image: torizon/weston:4
  cap_add:
    - CAP_SYS_TTY_CONFIG
  device_cgroup_rules:
    - 'c 4:0 rmw'
    - 'c 4:7 rmw' 
    - 'c 13:* rmw'
    - 'c 226:* rmw'
    - 'c 10:223 rmw'

Why Use the Built-in Service?

The docker-compose systemd service is specifically designed for Torizon OS and handles:

Proper startup timing with Docker daemon(1)
Container dependency management
Automatic restart behavior(1)
Integration with Torizon OS boot process

This approach eliminates the timing issues you experienced with touch input, as the service properly waits for all system components to be ready(1).

Reboot and Test

After making these changes, reboot your system to test the autorun functionality:

sudo reboot

Your containers should start automatically, and touch input should work reliably since the built-in service handles proper initialization timing(1).

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.

Coders · April 2, 2026, 5:09am

Thank you for quick response @ToradexAI but when I started and check status of sevice then its showing below output so monitior it or Please telll me what i need to do for solve or only restart will work perfect for below output
● docker-compose.service - Docker Compose service with docker compose
Loaded: loaded (/usr/lib/systemd/system/docker-compose.service; enabled; preset: enabled)
Active: active (exited) since Thu 2026-04-02 03:45:04 UTC; 1h 22min ago
Main PID: 785 (code=exited, status=0/SUCCESS)
CPU: 622ms

Apr 02 03:45:04 colibri-imx7-emmc-06673340 systemd[1]: Starting Docker Compose service with docker compose…
Apr 02 03:45:04 colibri-imx7-emmc-06673340 systemd[1]: Started Docker Compose service with docker compose.
Apr 02 03:45:06 colibri-imx7-emmc-06673340 docker-compose[785]: Container torizon-spimodule-debug-1 Stopping
Apr 02 03:45:06 colibri-imx7-emmc-06673340 docker-compose[785]: Container torizon-spimodule-debug-1 Stopped
Apr 02 03:45:06 colibri-imx7-emmc-06673340 docker-compose[785]: Container torizon-spimodule-debug-1 Removing
Apr 02 03:45:06 colibri-imx7-emmc-06673340 docker-compose[785]: Container torizon-spimodule-debug-1 Removed
Apr 02 03:45:06 colibri-imx7-emmc-06673340 docker-compose[785]: Container torizon-weston-1 Created
Apr 02 03:45:06 colibri-imx7-emmc-06673340 docker-compose[785]: Container torizon-weston-1 Starting
Apr 02 03:45:07 colibri-imx7-emmc-06673340 docker-compose[785]: Container torizon-weston-1 Started

ToradexAI · April 2, 2026, 5:10am

Service Status Analysis

The service status shows that the docker-compose service is working correctly. The status active (exited) is normal behavior for the docker-compose service (1). This means the service successfully started your containers and then exited, which is the expected behavior.

Checking Container Status

To verify that your containers are actually running, use:

docker ps

This will show if both your Weston and application containers are currently active.

Troubleshooting Missing Application Container

I notice from the logs that only the Weston container (torizon-weston-1) was started. Your application container might not be starting due to dependency issues. The docker-compose service uses depends_on to manage startup order (2).

Verify Your Docker-Compose File Location

Ensure your complete docker-compose.yml file is in the correct location:

ls -la /var/sota/storage/docker-compose/docker-compose.yml
cat /var/sota/storage/docker-compose/docker-compose.yml

Check Container Logs

If your application container isn’t starting, check the logs:

docker logs torizon-app-1

Manual Testing

You can also test the docker-compose file manually from the correct directory:

cd /var/sota/storage/docker-compose/
docker-compose up

Service Restart Behavior

The docker-compose service is designed to start containers at boot and then exit (1). If you need to restart the containers after making changes to the docker-compose.yml file, you can:

sudo systemctl restart docker-compose.service

Expected Behavior

After a reboot, both containers should start automatically. The service status showing active (exited) with successful container creation is the correct behavior - it indicates the service completed its task of starting your containers (1).

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.

jeremias.tx · April 2, 2026, 4:05pm

Hi @Coders,

It’s not clear from your last message what the current issue is. As per the logs from the systemd service it seems like the service executed successfully.

Please describe in clearer detail what the current issue you are observing is exactly.

Best Regards,
Jeremias

Coders · April 3, 2026, 4:16am

I want to run my PySide2 application in autorun mode, and I am unsure whether I should use a systemd service or a Docker-based service.
Currently, I am deploying my application through Torizon Cloud, where my device is attached. With this setup, the autorun requirement is already handled when the application is deployed.
I am running my application using Weston to support both touch and mouse input.
Although autorun is working correctly, I am facing an issue with the mouse cursor:

When I connect a USB mouse after the application has booted, the cursor does not appear.
However, inside the container, I can see input devices like event0, event1, and event2, which indicates that the system detects the mouse.

I would like to ensure that:

When a mouse is connected after boot the cursor appears automatically.
The mouse works correctly without restarting the application or container.

Below is my current docker-compose.yml setup for Weston and the application:
services:
weston:
image: torizon/weston:4
restart: always
privileged: true
command: [“–developer”]
environment:
- XDG_RUNTIME_DIR=/run/user/1000
volumes:
- /tmp:/tmp
- /run/udev:/run/udev
- /run/user/1000:/run/user/1000
- /dev/input:/dev/input
group_add:
- input
device_cgroup_rules:
- ‘c 13:* rmw’
- ‘c 226:* rmw’

app:
image: intersense123/octo:3
privileged: true
restart: always
depends_on:
- weston
environment:
- QT_QPA_PLATFORM=wayland
- WAYLAND_DISPLAY=wayland-0
- XDG_RUNTIME_DIR=/run/user/1000
cap_add:
- SYS_TIME
- NET_ADMIN
- SYS_BOOT
volumes:
- /tmp:/tmp
- /dev/input:/dev/input
- /media:/media
- /sys:/sys
- /etc/machine-id:/etc/machine-id:ro
- /etc/localtime:/etc/localtime:ro
- /etc/timezone:/etc/timezone:ro
- /var/run/systemd:/var/run/systemd
- /run/dbus:/run/dbus
- /run/udev:/run/udev
- /run/user/1000:/run/user/1000
- /home/torizon/Precigo/precigo.db:/home/torizon/app/precigo.db
- /home/torizon/Precigo/OctoPreciGo.db:/home/torizon/app/OctoPreciGo.db
- /home/torizon/Precigo/Octo_CSV:/home/torizon/app/Octo_CSV
devices:
- /dev/ttymxc0
- /dev/rtc0
- /dev/rtc1
group_add:
- input
device_cgroup_rules:
- ‘c 13:* rmw’
network_mode: host
Could you please review this setup and guide me on how to resolve the mouse cursor issue after boot, especially when the mouse is connected dynamically? @jeremias.tx @ToradexAI

ToradexAI · April 3, 2026, 4:17am

I’d be glad to help with your mouse cursor issue! To provide the most accurate guidance, could you let me know which exact version of Torizon OS you are running on your i.MX7 device?

You can get this information by running the tdx-info command on your device.

Mouse Cursor Configuration for Dynamic Connection

For your mouse cursor issue when connecting USB devices after boot, your Weston configuration needs proper device access rules. Based on the Torizon documentation, here’s the recommended Weston configuration for i.MX7 (1):

weston:
  image: torizon/weston:4
  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
  device_cgroup_rules:
    - 'c 4:* rmw'
    - 'c 13:* rmw'
    - 'c 226:* rmw'
    - 'c 10:223 rmw'
  command: --developer

Key Configuration Changes

Use network_mode: host instead of privileged mode for Weston (1)
Mount full /dev directory to ensure all input devices are accessible (1)
Include proper device cgroup rules for input devices (c 13:* rmw) and other hardware access (1)
Mount /run/udev to receive hotplug events for dynamically connected devices (1)

Autorun Deployment Method

Since you’re using Torizon Cloud for deployment, you’re already using the recommended approach (2). The docker-compose service automatically handles container startup at boot when deployed through Torizon Cloud (2).

Troubleshooting Dynamic Mouse Connection

The issue with mouse cursors not appearing when connected after boot is typically related to:

Incomplete device access permissions
Missing udev event handling
Insufficient hardware access rules

Your updated configuration should resolve this by ensuring Weston can detect and respond to hotplug events for USB input devices.

Could you also specify which carrier board you’re using with your i.MX7 (e.g., Ixora, Iris, or custom carrier board)? This will help ensure the device access rules are complete for your specific hardware setup.

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.

Coders · April 3, 2026, 4:22am

below is tdx-info
Software summary

Bootloader: U-Boot
Kernel version: 6.6.108-7.4.0-00057-g451f1e35226f #1-Torizon SMP PREEMPT Mon Jun 30 14:11:55 UTC 2025
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/22d58afd3489301015d8dd92011adee7c16b9fe8bedfe39c90cb8b42e0278e8d/0
Distro name: NAME=“Torizon OS Upstream”
Distro version: VERSION_ID=7.4.0-build.28
Distro variant: VARIANT=“Docker”
Hostname: colibri-imx7-emmc-06673340

Hardware info

HW model: Toradex Colibri iMX7D 1GB (eMMC) on Colibri Evaluation Board V3
Toradex version: 0039 V1.1A
Serial number: 06673340
Processor arch: armv7l

take a look of it and give me suggestion to solve above cursor problem @ToradexAI

ToradexAI · April 3, 2026, 4:23am

Perfect! Based on your setup (Torizon OS 7.4.0 on Colibri iMX7D with Evaluation Board V3), here’s the solution for your mouse cursor issue:

Mouse Cursor Configuration for Torizon OS 7

For your Colibri iMX7D on Torizon OS 7.4.0, you need to use the correct Weston configuration for i.MX6/i.MX7 modules (1):

services:
  weston:
    image: torizon/weston:4
    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
    device_cgroup_rules:
      - 'c 4:* rmw'
      - 'c 13:* rmw'
      - 'c 226:* rmw'
      - 'c 10:223 rmw'
    command: --developer

(1)

Key Changes for Dynamic Mouse Support

Remove privileged: true - Replace with specific device access rules (1)
Mount full /dev directory - This ensures all input devices are accessible when hotplugged (1)
Include /run/udev mount - Essential for receiving hotplug events for USB devices (1)
Use network_mode: host - Required for proper hardware access (1)

Complete Working Docker-Compose Configuration

services:
  weston:
    image: torizon/weston:4
    restart: always
    network_mode: host
    volumes:
      - /tmp:/tmp
      - /dev:/dev
      - /run/udev:/run/udev
    cap_add:
      - CAP_SYS_TTY_CONFIG
    device_cgroup_rules:
      - 'c 4:* rmw'
      - 'c 13:* rmw'
      - 'c 226:* rmw'
      - 'c 10:223 rmw'
    command: --developer

  app:
    image: intersense123/octo:3
    restart: always
    depends_on:
      - weston
    environment:
      - QT_QPA_PLATFORM=wayland
      - WAYLAND_DISPLAY=wayland-0
      - XDG_RUNTIME_DIR=/tmp/1000-runtime-dir
    volumes:
      - /tmp:/tmp
      - /dev:/dev
      - /run/udev:/run/udev
      - /media:/media
      - /sys:/sys
      - /etc/machine-id:/etc/machine-id:ro
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
      - /var/run/systemd:/var/run/systemd
      - /run/dbus:/run/dbus
      - /home/torizon/Precigo/precigo.db:/home/torizon/app/precigo.db
      - /home/torizon/Precigo/OctoPreciGo.db:/home/torizon/app/OctoPreciGo.db
      - /home/torizon/Precigo/Octo_CSV:/home/torizon/app/Octo_CSV
    devices:
      - /dev/ttymxc0
      - /dev/rtc0
      - /dev/rtc1
    cap_add:
      - SYS_TIME
      - NET_ADMIN
      - SYS_BOOT
    device_cgroup_rules:
      - 'c 13:* rmw'
    network_mode: host

Why This Fixes the Mouse Cursor Issue

The key improvements are:

Full /dev access ensures all USB input devices are available to Weston (1)
udev integration allows Weston to detect and respond to hotplug events (1)
Proper device cgroup rules provide the necessary permissions for input device access (1)

This configuration follows the official Torizon documentation for i.MX6/i.MX7 modules and should resolve your mouse cursor visibility issue when connecting USB mice after boot (1).

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.

Coders · April 3, 2026, 4:58am

Thank you for solution Issue Solved Successfully.

jeremias.tx · April 3, 2026, 5:14pm

Glad to hear your issues was resolved.

Best Regards,
Jeremias

How to set a PySide2 application to autorun on Weston (Torizon OS, i.MX7)?

Wait for Wayland

Wait for input subsystem

Wait for udev (VERY IMPORTANT)

Small delay for stability

Run docker properly

Autorun Configuration for PySide2 Application on Torizon OS

Recommended Autorun Setup

Container Configuration Improvements

Environment Variables for GUI Applications

Touch Input Configuration

Container Restart Behavior

Production Deployment

Next Steps for Autorun Configuration

Remove Your Custom Service

Enable the Built-in Docker-Compose Service

Verify the Setup

Configuration Improvements

Why Use the Built-in Service?

Reboot and Test

Service Status Analysis

Checking Container Status

Troubleshooting Missing Application Container

Verify Your Docker-Compose File Location

Check Container Logs

Manual Testing

Service Restart Behavior

Expected Behavior

Mouse Cursor Configuration for Dynamic Connection

Key Configuration Changes

Autorun Deployment Method

Troubleshooting Dynamic Mouse Connection

below is tdx-info Software summary

Hardware info

HW model: Toradex Colibri iMX7D 1GB (eMMC) on Colibri Evaluation Board V3 Toradex version: 0039 V1.1A Serial number: 06673340 Processor arch: armv7l

Mouse Cursor Configuration for Torizon OS 7

Key Changes for Dynamic Mouse Support

Complete Working Docker-Compose Configuration

Why This Fixes the Mouse Cursor Issue

below is tdx-info
Software summary

HW model: Toradex Colibri iMX7D 1GB (eMMC) on Colibri Evaluation Board V3
Toradex version: 0039 V1.1A
Serial number: 06673340
Processor arch: armv7l