Greetings @jeremias.tx.
In this post, you will find our recent test results.
In general, you can find to tests and all of them have been created on the basis of the device tree provided in post (cf. 30th of August, file called imx8-apalis-sensgit-v1.1.dts.
Furthermore, we have validated this with our productive device tree. Results are similar, here.
Hence, we assume, this is not an issue of the device trees.
You will find two test cases:
-
Mirroring displays (weston.ini modification)
-
Having two parallel weston containers running:
Let’s face each test case individually. Before, let’s sum up what we know and focus on relevant weston log lines from our tests:
- Starting container called
weston_d1
(result: display 1 starts successfully and shows weston surface).
[18:01:07.708] launching '/usr/lib/aarch64-linux-gnu/weston-desktop-shell'
[18:01:07.738] unknown child process exited
[18:01:07.738] unknown child process exited
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'
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'
- Starting container called
weston_d2
(result: display 2 starts successfully and shows weston surface)
[18:01:46.171] launching '/usr/lib/aarch64-linux-gnu/weston-desktop-shell'
[18:01:46.171] xserver listening on display :0
[18:01:46.171] launching '/usr/lib/aarch64-linux-gnu/weston-desktop-shell'
[18:01:46.201] unknown child process exited
[18:01:46.201] unknown child process exited
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'
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'
Here, you have seen two log files when everything works fine, weston container starts correctly and weston surface shows up on the corresponding displays.
Let’s come to the issues…
- Starting container called
weston_dd
(result: nothing can be seen from weston surface, standard linux command promt is shown as always on display 2 as it shows up after booting torizon and having logged in)
[18:04:07.844] launching '/usr/lib/aarch64-linux-gnu/weston-desktop-shell'
[18:04:07.875] atomic: couldn't commit new state: Invalid argument
[18:04:07.875] repaint-flush failed: Invalid argument
[18:04:07.875] unknown child process exited
[18:04:07.875] atomic: couldn't commit new state: Invalid argument
[18:04:07.875] repaint-flush failed: Invalid argument
[18:04:07.875] unknown child process exited
could not load cursor 'dnd-move'
could not load cursor 'dnd-move'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
could not load cursor 'dnd-move'
could not load cursor 'dnd-move'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
As a reminder, see the ‘repaint-flush failed’ and ‘atomic: couldn’t commit new state: invalid argumets’ lines. So far, we still think, these two lines indicate the issue…
Let’s come to the tests…
1) Mirroring displays (weston.ini modification):
For easy checking and reproducing these results, you can find weston_dd_d1
here and weston_dd_d2
here, like the weston_dd
.
- Starting container called
weston_dd_d1
(result: although display 1 should clone display 2, nothing can be seen from weston surface, standard linux command promt is shown as always).
[18:02:27.593] launching '/usr/lib/aarch64-linux-gnu/weston-desktop-shell'
[18:02:27.647] atomic: couldn't commit new state: Invalid argument
[18:02:27.648] repaint-flush failed: Invalid argument
[18:02:27.648] unknown child process exited
[18:02:27.647] atomic: couldn't commit new state: Invalid argument
[18:02:27.648] repaint-flush failed: Invalid argument
[18:02:27.648] unknown child process exited
could not load cursor 'dnd-move'
could not load cursor 'dnd-move'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
could not load cursor 'dnd-none'
could not load cursor 'dnd-move'
could not load cursor 'dnd-move'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
could not load cursor 'dnd-none'
We think, this refers to the same error than the one of container called weston_dd
.
See the ‘repaint-flush failed’ and ‘atomic: couldn’t commit new state: invalid argumets’ lines.
- Starting container called
weston_dd_d2
(result: although display 2 should clone display 1, nothing can be seen from weston surface, standard linux command promt is shown as always)
[18:03:16.177] launching '/usr/lib/aarch64-linux-gnu/weston-desktop-shell'
[18:03:16.207] atomic: couldn't commit new state: Invalid argument
[18:03:16.207] atomic: couldn't commit new state: Invalid argument
[18:03:16.207] repaint-flush failed: Invalid argument
[18:03:16.207] unknown child process exited
[18:03:16.207] repaint-flush failed: Invalid argument
[18:03:16.207] unknown child process exited
could not load cursor 'dnd-move'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-move'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
could not load cursor 'dnd-none'
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'
We think, this refers to the same error than the one of container called weston_dd
.
See the ‘repaint-flush failed’ and ‘atomic: couldn’t commit new state: invalid argumets’ lines.
2. Having two parallel weston containers running:
Let’s come to the second test.
Here, we intended to start one weston container for display 1 and one weston container for display 2.
Because of conflict potential among ttys of containers, we have chosen tty7 and tty8.
Both tty (tty7;tty8) options successfully have worked with container (1) and (2).
- Start the first display with container (1) called
weston_d1
on tty8.
- docker run -d --rm --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 13:* rmw’ --device-cgroup-rule=‘c 199:* rmw’ --device-cgroup-rule=‘c 226:* rmw’ bdockeridsens/weston_d1:latest --developer weston-launch --tty=/dev/tty8 --user=torizon
[18:05:18.253] Registered plugin API 'weston_xwayland_surface_v1' of size 16
[18:05:18.253] xserver listening on display :0
[18:05:18.253] xserver listening on display :0
[18:05:18.253] launching '/usr/lib/aarch64-linux-gnu/weston-desktop-shell'
[18:05:18.253] launching '/usr/lib/aarch64-linux-gnu/weston-desktop-shell'
[18:05:18.307] unknown child process exited
[18:05:18.307] unknown child process exited
could not load cursor 'dnd-move'
could not load cursor 'dnd-move'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
could not load cursor 'dnd-none'
could not load cursor 'dnd-move'
could not load cursor 'dnd-move'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
could not load cursor 'dnd-none'
Result: display 1 starts successfully and shows weston surface.
- Start the second display with container (2) called
weston_d2
on tty7.
- docker run --rm --name=weston2 --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 13:* rmw’ --device-cgroup-rule=‘c 199:* rmw’ --device-cgroup-rule=‘c 226:* rmw’ bdockeridsens/weston_d2:latest --developer weston-launch --tty=/dev/tty7 --user=torizon
NXP EULA has already been accepted.
SoC is: 'i.MX8QM'
SoC has GPU: false
SoC has DPU: false
g2d implementation: viv
Fallbacking to software renderer.
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.
NXP EULA has already been accepted.
touch: cannot touch '/tmp/nxp-eula-accepted': Permission denied
touch: cannot touch '/tmp/nxp-eula-accepted': Permission denied
Date: 2021-09-01 UTC
[18:07:18.124] weston 9.0.0
Result: display 1 and display 2 become black (they crash because argument IGNORE_X_LOCKS=1
has not been specified.
[18:05:18.253] Registered plugin API 'weston_xwayland_surface_v1' of size 16
[18:05:18.253] xserver listening on display :0
[18:05:18.253] xserver listening on display :0
[18:05:18.253] launching '/usr/lib/aarch64-linux-gnu/weston-desktop-shell'
[18:05:18.253] launching '/usr/lib/aarch64-linux-gnu/weston-desktop-shell'
[18:05:18.307] unknown child process exited
[18:05:18.307] unknown child process exited
could not load cursor 'dnd-move'
could not load cursor 'dnd-move'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
could not load cursor 'dnd-none'
could not load cursor 'dnd-move'
could not load cursor 'dnd-move'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
could not load cursor 'dnd-none'
Result: display 1 starts successfully and shows weston surface.
- Start the second display with container (2) called
weston_d2
on tty7 with IGNORE_X_LOCKS=1
.
- docker run -e IGNORE_X_LOCKS=1 --rm --name=weston2 --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 13:* rmw’ --device-cgroup-rule=‘c 199:* rmw’ --device-cgroup-rule=‘c 226:* rmw’ bdockeridsens/weston_d2:latest --developer weston-launch --tty=/dev/tty7 --user=torizon
[18:11:44.497] Registered plugin API 'weston_drm_output_api_v1' of size 24
[18:11:44.497] Registered plugin API 'weston_drm_output_api_v1' of size 24
[18:11:44.497] Registered plugin API 'weston_drm_virtual_output_api_v1' of size 48
[18:11:44.497] Registered plugin API 'weston_drm_virtual_output_api_v1' of size 48
[ 1] DRM_IOCTL_PRIME_FD_TO_HANDLE failed (fd=25)
[ 2] ioctl(DRM_IOCTL_GEM_CLOSE) failed
[ 1] DRM_IOCTL_PRIME_FD_TO_HANDLE failed (fd=25)
[ 2] ioctl(DRM_IOCTL_GEM_CLOSE) failed
[ 3] DRM_IOCTL_PRIME_FD_TO_HANDLE failed (fd=25)
[ 4] ioctl(DRM_IOCTL_GEM_CLOSE) failed
[ 3] DRM_IOCTL_PRIME_FD_TO_HANDLE failed (fd=25)
[ 4] ioctl(DRM_IOCTL_GEM_CLOSE) failed
[18:11:44.498] failed to create gbm surface
[18:11:44.498] Failed to init output gl state
[18:11:44.498] failed to create gbm surface
[18:11:44.498] Failed to init output gl state
[18:11:44.498] Enabling output "LVDS-2" failed.
[18:11:44.498] Error: cannot enable output 'LVDS-2' without heads.
[18:11:44.498] Enabling output "LVDS-2" failed.
[18:11:44.498] Error: cannot enable output 'LVDS-2' without heads.
[18:11:44.499] event2 - Goodix Capacitive TouchScreen: device removed
[18:11:44.499] event1 - gpio-keys: device removed
[18:11:44.499] event0 - sc-powerkey: device removed
[18:11:44.499] event2 - Goodix Capacitive TouchScreen: device removed
[18:11:44.499] event1 - gpio-keys: device removed
Result: display 1 and display 2 become black (they crash).
Here, we see new error lines, which is great because we have an indication.
Having done Internet research, it seems to be a kernel-related IOCTL-problem.
It seems that the file descriptor is already in use by DRM of the first container, when the DRM of the second container wants to use it.
A rough idea (this is effortful, complicated) is the following:
First, we need to switch off LVDS-1 with the aid of weston.ini
similar to container weston_d2
:
[output]
name=LVDS-1
mode=off
Furthermore, we need to start with modified docker run
commands the following: first, container (1) called weston_d1
and second, container (2) called weston_d2
taking only that parts of volumes into account that are realy really needed for the specific display. We assume that parameter -v /dev:/dev
needs to be specialized somehow…
What do you think about this idea?
Do you have alternative ideas?
Up to here, thank you very much for taking your time to read this huge post.
It was great if you could rerun these tests and share your results regarding weston_dd_d1
and weston_dd_d2
.
How can we proceed?
How can we support your testing?
We are looking forward to hearing from you.
Best regards,
Marcus