I’m currently using the verdin dev board with an imx8mp and the 7” touchscreen. I’d like to simulate a different display that is 4.3” and has a resolution of 480x272. Is there a way to configure weston to use those dimensions and resolutions on my 7”? I’m not using qt.
Thanks!
Hi, I’m the Toradex AI Assistant.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
Yes, you can configure Weston to use a fixed display resolution of 480x272 on your 7" touchscreen to simulate a 4.3" display (1).
Weston supports setting the resolution in the configuration file (1). You’ll need to modify the weston.ini file to specify your desired resolution.
To configure this, you can add the following configuration to your weston.ini file (1):
[output]
name=DSI-1
mode=480x272
The name value can be found by executing weston-info from inside the running Weston container (1).
For detailed information on how to apply configuration options to Weston, refer to the configuration section in the Weston documentation (1). The pre-defined weston.ini and weston-dev.ini files include comments that illustrate how to set up display resolution configurations (1).
For more details about display configuration and resolution settings, you can refer to the weston-drm documentation (1).
This approach will effectively simulate your 4.3" display dimensions on the 7" touchscreen by constraining the display output to the 480x272 resolution.
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 Won’t this simulate just the resolution and not the 4.3 dimension?
@ToradexAI Won’t this simulate just the resolution and not the 4.3” dimensions?
You’re absolutely correct! The Weston configuration I mentioned will only simulate the resolution (480x272 pixels) but not the actual physical dimensions of a 4.3" display (1).
When you configure Weston with:
[output]
name=DSI-1
mode=480x272
This setting only changes the pixel resolution that Weston outputs (1). Your 7" display will still be physically 7 inches, but it will only use a 480x272 pixel area, likely appearing as a small window or scaled content on the larger screen.
The physical size of your display is determined by the hardware itself - in this case, your 7" touchscreen. Weston cannot change the actual physical dimensions of the display panel. The configuration only affects:
With the 480x272 resolution setting on your 7" display, you would typically see one of these behaviors:
The exact behavior depends on how your display controller and Weston handle the resolution mismatch between the configured output and the physical display capabilities.
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 The mode change doesn’t seem to work with this setup. Here are the docker logs for weston. I would suspect the video modes would reflect the new mode I set? And I am sure it’s using my customized weston.ini.
docker run -d --name=chromium \
–network=host \
-e ACCEPT_FSL_EULA=1 \
-e WAYLAND_DISPLAY=wayland-0 \
-v /tmp:/tmp -v /var/run/dbus:/var/run/dbus \
–device /dev/dri --device /dev/galcore \
–security-opt seccomp=unconfined \
–shm-size 256mb \
torizon/chromium-imx8:4 \
–incognito \
–enable-features=UseOzonePlatform \
–ozone-platform=wayland \
–browser-mode \
–virtual-keyboard http://localhost:8080
I notice you’re running the Chromium container but haven’t shown the Weston container setup or its logs. The Chromium container connects to an existing Weston compositor - it doesn’t create one (1).
You need to run a separate Weston container first. For your Verdin iMX8M Plus with 7" DSI display, use:
# 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 253:* rmw" \
--device-cgroup-rule="c 13:* rmw" --device-cgroup-rule="c 226:* rmw" \
--device-cgroup-rule="c 10:223 rmw" --device-cgroup-rule="c 199:0 rmw" \
torizon/weston-imx8:4 \
--developer
To use your custom weston.ini file, you have two options (2):
For evaluation/prototyping - bind mount your custom configuration:
-v <path_to_directory_containing_weston.ini_file>:/etc/xdg/weston/
For development/production - build your own Weston Docker image with the custom configuration file (2).
Once you have the Weston container running, check its logs to see if your configuration is being applied:
# docker logs weston
To determine the correct output name for your configuration, execute weston-info from inside the running Weston container (3). The output name you use in your weston.ini must match exactly what weston-info reports.
The Chromium container you’re running connects to the Weston compositor via the Wayland socket, but Weston itself must be running first with your custom configuration applied.
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 oops…here is the docker logs weston:
torizon@verdin-imx8mp-15703259:/var/lib/weston-ini$ docker logs weston
Switching VT tty7 to text mode if currently in graphics mode
Switching VT mode of /dev/tty7 to text
Switching to VT 7
SoC is: ‘i.MX8MP’
SoC has GPU: true
SoC has DPU: false
g2d implementation: viv
Removing previously created ‘.X*-lock’ entries under /tmp before starting Weston. Pass ‘IGNORE_X_LOCKS=1’ environment variable to Weston container to disable this behavior.
dos2unix: converting file /etc/xdg/weston/weston.ini to Unix format…
dos2unix: converting file /etc/xdg/weston-dev/weston.ini to Unix format…
00:00:00.000 [INFO] [seatd/seat.c:39] Created VT-bound seat seat0
00:00:00.000 [INFO] [seatd/seatd.c:194] seatd started
Date: 2025-10-23 UTC
[17:48:05.340] weston 12.0.4
https://wayland.freedesktop.org
Bug reports to: Making sure you're not a bot!
Build: 12.0.4
[17:48:05.340] Command line: weston -Bdrm-backend.so -Swayland-0 --use-g2d
[17:48:05.340] OS: Linux, 6.6.94-7.3.0-g5a62539de8f9, #1-Torizon SMP PREEMPT Wed Jun 25 09:14:55 UTC 2025, aarch64
[17:48:05.340] Flight recorder: enabled
[17:48:05.340] Using config file ‘/etc/xdg/weston/weston.ini’
[17:48:05.341] Output repaint window is 7 ms maximum.
[17:48:05.341] Loading module ‘/usr/lib/aarch64-linux-gnu/libweston-12/drm-backend.so’
[17:48:05.348] initializing drm backend
[17:48:05.349] Trying libseat launcher…
00:00:00.021 [INFO] [seatd/server.c:145] New client connected (pid: 30, uid: 1000, gid: 1000)
00:00:00.021 [INFO] [seatd/seat.c:170] Added client 7 to seat0
00:00:00.021 [INFO] [seatd/seat.c:480] Opened client 7 on seat0
[17:48:05.349] [libseat/libseat.c:73] Seat opened with backend ‘seatd’
[17:48:05.349] [libseat/backend/seatd.c:212] Enabling seat
[17:48:05.349] libseat: session control granted
[17:48:05.352] using /dev/dri/card0
[17:48:05.353] DRM: supports atomic modesetting
[17:48:05.353] DRM: does not support GBM modifiers
[17:48:05.353] DRM: does not support async page flipping
[17:48:05.353] DRM: supports picture aspect ratio
[17:48:05.353] Loading module ‘/usr/lib/aarch64-linux-gnu/libweston-12/g2d-renderer.so’
[17:48:05.500] event1 - gpio-keys: is tagged by udev as: Keyboard
[17:48:05.500] event1 - gpio-keys: device is a keyboard
[17:48:05.504] event0 - 30370000.snvs:snvs-powerkey: is tagged by udev as: Keyboard
[17:48:05.504] event0 - 30370000.snvs:snvs-powerkey: device is a keyboard
[17:48:05.509] event2 - ilitek_ts: is tagged by udev as: Touchscreen
[17:48:05.509] event2 - ilitek_ts: device is a touch device
[17:48:05.537] libinput: configuring device “gpio-keys”.
[17:48:05.538] libinput: configuring device “30370000.snvs:snvs-powerkey”.
[17:48:05.538] Touchscreen - ilitek_ts - /sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-0041/input/input2/event2
[17:48:05.538] libinput: configuring device “ilitek_ts”.
[17:48:05.538] input device event2 has no enabled output associated (none named), skipping calibration for now.
[17:48:05.538] DRM: head ‘LVDS-1’ found, connector 35 is connected, EDID make ‘unknown’, model ‘unknown’, serial ‘unknown’
Supported EOTF modes: SDR
[17:48:05.539] Registered plugin API ‘weston_drm_output_api_v1’ of size 40
[17:48:05.539] Registered plugin API ‘weston_drm_virtual_output_api_v2’ of size 48
[17:48:05.539] Color manager: no-op
[17:48:05.539] Module ‘/usr/lib/aarch64-linux-gnu/libgbm.so’ already loaded
[17:48:05.539] Output ‘LVDS-1’ attempts EOTF mode: SDR
[17:48:05.539] Output ‘LVDS-1’ using color profile: built-in default sRGB SDR profile
[17:48:05.542] Initialized backlight for head ‘LVDS-1’, device /sys/class/backlight/backlight
[17:48:05.542] Output LVDS-1 (crtc 33) video modes:
1024x600@59.1, preferred, current, 51.2 MHz
[17:48:05.542] associating input device event1 with output LVDS-1 (none by udev)
[17:48:05.542] associating input device event0 with output LVDS-1 (none by udev)
[17:48:05.542] associating input device event2 with output LVDS-1 (none by udev)
[17:48:05.543] Output ‘LVDS-1’ enabled with head(s) LVDS-1
[17:48:05.543] Compositor capabilities:
arbitrary surface rotation: yes
screen capture uses y-flip: yes
cursor planes: yes
arbitrary resolutions: no
view mask clipping: yes
explicit sync: yes
color operations: no
presentation clock: CLOCK_MONOTONIC, id 1
presentation clock resolution: 0.000000001 s
[17:48:05.544] Loading module ‘/usr/lib/aarch64-linux-gnu/weston/desktop-shell.so’
[17:48:05.545] Loading module ‘/usr/lib/aarch64-linux-gnu/libweston-12/xwayland.so’
[17:48:05.569] Registered plugin API ‘weston_xwayland_v1’ of size 32
[17:48:05.569] Registered plugin API ‘weston_xwayland_surface_v1’ of size 16
[17:48:05.569] xserver listening on display :0
[17:48:05.569] launching ‘/usr/lib/aarch64-linux-gnu/weston-keyboard’
[17:48:05.575] launching ‘/usr/lib/aarch64-linux-gnu/weston-desktop-shell’
could not load cursor ‘dnd-move’
could not load cursor ‘dnd-copy’
could not load cursor ‘dnd-none’
could not load cursor ‘dnd-move’
could not load cursor ‘dnd-copy’
could not load cursor ‘dnd-none’
Based on your Weston logs, I can see several key points:
Using config file '/etc/xdg/weston/weston.ini' (1)DRM: head 'LVDS-1' found and Output LVDS-1 (crtc 33) video modes: 1024x600@59.1, preferred, current, 51.2 MHzYour display is being detected as LVDS-1, not DSI-1. You need to update your weston.ini configuration to use the correct output name:
[output]
name=LVDS-1
mode=480x272
The logs indicate Weston is using the default /etc/xdg/weston/weston.ini file (1). You need to ensure your custom configuration is properly mounted.
For evaluation and prototyping, you can bind mount a custom configuration file by adding a volume flag to the docker run command:
-v <path_to_directory_containing_weston.ini_file>:/etc/xdg/weston/
Since you’re using the --developer switch, Weston will use /etc/xdg/weston-dev/weston.ini instead of the default file (1). Make sure your custom configuration is placed in the correct location or mounted to the right path.
The corrected Docker command should include the volume mount for your custom configuration directory.
Important Note: The weston.ini file is sensitive to trailing whitespaces after configuration names and options. If a configuration is not applied correctly, check if there are whitespaces between text and line breaks (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.
@ToradexAI I’m using the 7” touchscreen on the verdin dev board. The correct name is LVDS-1 (that’s what I’m using and that does work).
I’m using a directory /var/lib/weston-ini on the dev board to house the new weston.ini and start the container with:
-v /var/lib/weston-ini:/etc/xdg/weston \
-v /var/lib/weston-ini:/etc/xdg/weston-dev \
So it does see and use my custom config. I looked at it in the running container and verified.
I’m not using the developer switch.
Based on your setup description and the Weston logs, your configuration mounting is correct, but there may be an issue with how Weston is handling the custom mode setting.
Looking at your logs, the display is showing:
Output LVDS-1 (crtc 33) video modes:
1024x600@59.1, preferred, current, 51.2 MHz
This suggests that your display hardware may only support specific video modes, and 480x272 might not be a supported mode for your 7" touchscreen (1).
Since the standard mode=480x272 setting isn’t working, you could try these approaches in your weston.ini file (1):
[output]
name=LVDS-1
transform=rotate-0
weston-info from inside the running Weston container to see all available video modes (1).The 7" Capacitive Touch Display has a native resolution of 800x480px (2), but your logs show 1024x600, which suggests you might be using a different display variant. The hardware may not support arbitrary resolution changes through software configuration alone.
weston-info to see what video modes are actually availableThe mode setting in Weston is hardware-dependent, and not all displays support arbitrary resolutions. Your 7" display controller may be limiting the available video modes to what it can physically support.
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 weston.ini is correct inside the running container. How do i run weston-info?
To run weston-info, you need to execute it from inside the running Weston container (1). Use the following command:
# docker exec weston weston-info
This will provide you with detailed information about your Wayland compositor, including available video modes and output capabilities.
You can also access the container interactively and then run weston-info:
# docker exec -it weston bash
# weston-info
The weston-info command will display information about:
This will help you verify what video modes are actually supported by your display hardware and confirm the correct output name to use in your weston.ini configuration (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.
@ToradexAI Doesn’t seem like weston-info is included with that toradex docker image? Here’s a listing from inside the container:
root@verdin-imx8mp-15703259:/home/torizon# ls /bin/weston*
/bin/weston /bin/weston-editor /bin/weston-scaler /bin/weston-simple-touch
/bin/weston-calibrator /bin/weston-eventdemo /bin/weston-screenshooter /bin/weston-smoke
/bin/weston-clickdot /bin/weston-flower /bin/weston-simple-damage /bin/weston-stacking
/bin/weston-cliptest /bin/weston-fullscreen /bin/weston-simple-dmabuf-egl /bin/weston-subsurfaces
/bin/weston-confine /bin/weston-image /bin/weston-simple-dmabuf-feedback /bin/weston-tablet
/bin/weston-content_protection /bin/weston-multi-resource /bin/weston-simple-dmabuf-v4l /bin/weston-terminal
/bin/weston-debug /bin/weston-presentation-shm /bin/weston-simple-egl /bin/weston-touch-calibrator
/bin/weston-dnd /bin/weston-resizor /bin/weston-simple-shm /bin/weston-transformed
root@verdin-imx8mp-15703259:/home/torizon#
You're correct - weston-info is not included in the Toradex Weston container image. This is a limitation of the current container.
From your earlier Weston logs, we can see the available video modes:
Output LVDS-1 (crtc 33) video modes:
1024x600@59.1, preferred, current, 51.2 MHz
This indicates that your display hardware only supports 1024x600 as the available video mode, which explains why the 480x272 mode setting isn't working.
You can try using weston-debug (which is available in your container) to get more information about the compositor:
# docker exec weston weston-debug
You can also check what modes are available at the DRM level from the host system:
# cat /sys/class/drm/card0-LVDS-1/modes
Based on the logs showing only 1024x600@59.1 as the available video mode, it appears your 7" display hardware is limited to this specific resolution. The display controller or panel itself may not support the 480x272 resolution you're trying to configure.
This means that setting mode=480x272 in your weston.ini won't work because the hardware doesn't support that video mode. Weston can only use modes that are supported by the underlying display hardware.
For your use case of simulating a 4.3" display, you would need to handle the resolution difference at the application level rather than at the compositor level, since the hardware is constraining the available video modes.
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.
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.
Hey @DaveM,
What type of screen are you working with? HDMI, LVDS, DSI?
Some of these values can be modified via the device tree.
See the paneling properties for this display:
Hey @eric.tx ,
Right now, I’m using a verdin dev board, imx8mp, 7” touchscreen from toradex connected via LVDS. We’re using this set up for development. Our production hardware will be a 4.3” 480x272 touchscreen (not sure of the hardware, that’s for the hardware guys 
). I’d like to “simulate” that display on the 7” in some way with the actual physical dimensions and lower resolution so folks don’t get used to the pretty 7”. I’ve been round and round with mode, modeline, scale in the weston.ini file (all to no avail), as it seems none of that can change in either the stock toradex docker image for weston or some other “hardware doesn’t like it” deal.
I got closer with just using chromium to establish a smaller window to run in, but then I have touch issues where that didn’t scale in and the touch was still active over the entire 7” glass.
I was hoping for some magic dust to sprinkle over the ini and/or docker run without modifying the html at all, but haven’t been that successful. Perhaps changing the device tree for the 7” might get me there, but I was hoping for a bit less intrusive method.
Thanks!
– Dave
Just an idea, if this is just for development, and to test things out a little bit, and you are using chromium, why not just use the chrome devtools device mode to set the resolution to 480x272 ?
That will get you the viewport at least, and the physical size might be off (though in theory you could tweak the resolution, at the expense of the viewport not technically being exactly the same resolution). That would be a pretty low entry bar to getting you close enough. Hard to completely verify how it will work on completely different hardware when you don’t even know exactly what that hardware will be.
I have routinely tested webapps on my local computer using a similar approach, without even having to setup hardware since it is quite often good enough of an approximation. The resolution matters a lot more then the physical dimensions being perfect in my experience, though not sure exactly how far off this would be from what you are trying to do. For what its worth, that resolution is within a couple tenths physically on my desktop monitor at 100% zoom.
@dTanks Thanks for the ideas! I actually was able to get chromium to start in a 480x272 viewport using some window-size stuff on invocation, but the touch was all wonky. I tried some touch scaling using udev and some event stuff, but couldn’t get that together. I’ll take a look at the chrome devtools and see if that can help.
Thanks!