Dual screen usage at imx8 not working

Dear Toradex community.

We are currently running two different types of displays with an apalis imx8 using Torizon (bullseye).
We have prepared three kinds of containers:

  1. Container (1) starting weston on display 1 (works great – see logfile “container_1_display1.txt”),

  2. container (2) starting weston on display 2 (works great – see logfile “container_2_display2.txt”) and

  3. container (3) starting weston on both displays (which does not show weston on any display – see logfile “container_3_display1_and_display2.txt”).

Attached to this post, you can see the weston logs of all three containers in logs.zip file.

Furhter, you can find the docker build files for the containers (1), (2) and (3) attached (corresponding files (weston_d1 for container (1), weston_d2 for container (2) and Weston_dd for container (3)).

Analyzing log outputs and differences, we noticed outputs of container (1) and (2) to be quite similar. Of course, display timings are different. Comparing (1) and (2) with (3), we noticed the following lines to be different at (3):

weston_1  | Output LVDS-1 (crtc 125) video modes:
weston_1  | 256x1920@62.3, preferred, current, 77.0 MHz
weston_1  | associating input device event2 with output LVDS-1 (none by udev)
weston_1  | associating input device event2 with output LVDS-1 (none by udev)
weston_1  | associating input device event1 with output LVDS-1 (none by udev)
weston_1  | associating input device event0 with output LVDS-1 (none by udev)
weston_1  | Output 'LVDS-1' enabled with head(s) LVDS-1
weston_1  | associating input device event1 with output LVDS-1 (none by udev)
weston_1  | associating input device event0 with output LVDS-1 (none by udev)
weston_1  | Output 'LVDS-1' enabled with head(s) LVDS-1
weston_1  | Chosen EGL config details: id:  41 rgba: 8 8 8 0 buf: 24 dep:  0 stcl: 0 int: 1-60 type: win|pix|pbf|swap_preserved vis_id: XRGB8888 (0x34325258)
weston_1  | Output LVDS-2 (crtc 38) video modes:
weston_1  | 1280x320@62.0, preferred, current, 36.0 MHz
weston_1  | Output 'LVDS-2' enabled with head(s) LVDS-2
[…]
weston_1  | Loading module '/usr/lib/aarch64-linux-gnu/weston/desktop-shell.so'
weston_1  | Chosen EGL config details: id:  41 rgba: 8 8 8 0 buf: 24 dep:  0 stcl: 0 int: 1-60 type: win|pix|pbf|swap_preserved vis_id: XRGB8888 (0x34325258)
weston_1  | Output LVDS-2 (crtc 38) video modes:
weston_1  | 1280x320@62.0, preferred, current, 36.0 MHz
weston_1  | Output 'LVDS-2' enabled with head(s) LVDS-2

Obviously LVDS-1 is enabled twice. It seems as if LVDS-2 is not associated for any reason.
Further, the following log lines are different, which only come up at container (3):

weston_1  | atomic: couldn't commit new state: Invalid argument
weston_1  | atomic: couldn't commit new state: Invalid argument
weston_1  | repaint-flush failed: Invalid argument

Here, we assume, this is a consequence of false association mentioned above.

Having done hours of researches, it seems that we have to specify additional environment variables, such as $WESTON_DISABLE_ATOMIC=Y. At least, there exists a patch (see https://patchwork.openembedded.org/patch/170999/ ). Having considered this variable at container (3), nothing changes at logs (see logfile “container_3_display1_and_display2_withEnvironmentVar.txt”).
We further tried to specify this variable at weston config file (weston-dev.ini, can be found here: https://github.com/toradex/debian-docker-images/blob/bullseye/weston/weston-dev.ini ). This has resulted in the same behavior. Maybe we have specified it in a wrong way…?
This has been one of our attempts (not working):

[core]
idle-time=0
require-input=false
xwayland=true
modules=screen-share.so
WESTON_DISABLE_ATOMIC=Y

Do you know advice at the failure analysis, how to proceed, how to specify these variables?

We have tested this with multiple displays and other LVDS resolutions. This all has shown the same effects… As container (3) works with imx6, we assume this to be an imx8-specific issue…

Hopefully you can help.

Best,

Marcus

logs.zip (13.5 KB)
weston_d1.zip (5.4 KB)
weston_d2.zip (5.4 KB)
weston_dd.zip (5.5 KB)

Greetings @Marcus,

Before investigating could you please answer/clarify the following questions:

  • In summary you have two different(?) LVDS displays correct?
  • What changes to the kernel/device-tree did you implement to enable these displays?
  • Also since you’re using two LVDS displays at the same time, I assume you’re using your own carrier board or some hardware adapter, is that correct?
  • Outside of the Weston containers, what is the behavior of these displays? For example do they both show the boot splash? How about the Linux terminal?
  • Finally what is the output of ls /sys/class/drm on the device?

Best Regards,
Jeremias

Greetings @jeremias.tx,

thank you for your recent reply. It’s great to see you at this post again - hope you are well.

Regarding to your questions, please find answers below:

In summary you have two different(?) LVDS displays correct?

  • A: Yes, that is correct.

What changes to the kernel/device-tree did you implement to enable these displays?

  • A: Attached, you can see the corresponding layer to enable these two different displays (see file “imx8-apalis-sensgit-v1.1.dts”). We have tested the configurations of “two times the same display type 1” or “two time the same display type 2”. Of course, the layer files have been modified correspondingly. However, these all show the same behavior on imx8 (see answer below regarding the behavior outside the Weston container) but they are working on imx6.

Also, since you’re using two LVDS displays at the same time, I assume you’re using your own carrier board or some hardware adapter, is that correct?

  • A: Yes, that is correct.

Outside of the Weston containers, what is the behavior of these displays? For example, do they both show the boot splash? How about the Linux terminal?

  • A: During the boot, first, linux terminal is shown at display 2 and display 1 remains black. Then, splash screen comes up on display 1. Here, display 2 is switched to black. After this, linux terminal shows up again on display 2. Here, display 1 switches to black again. When starting container (1) with compose-up command, display 1 shows white Weston desktop successfully. When starting container (2) with compose-up command, display 2 shows white Weston desktop successfully. When starting container (3) with compose-up command, both displays remain black, although docker shows that the container is running.

Finally, what is the output of ls /sys/class/drm on the device?

  • A: Please find the output below:
    # ls /sys/class/drm 
    card0  card0-LVDS-1  card0-LVDS-2  card1  renderD128  renderD129  version 
    By the way: 
    # cat /sys/class/drm/card0-LVDS-1/status 
    connected 
    # cat /sys/class/drm/card0-LVDS-2/status 
    connected 

Hopefully, this input helps. We are looking forward to your answer.

Best,

Marcus

imx8-apalis-sensgit-v1.1.dts (4.0 KB)

Thank you for the additional information. With this, it’s confirmed that each display is setup correctly and operational. At least separately.

Reason I asked for the /sys/class/drm output is that there’s a limitation with Weston where it doesn’t handle multiple GPU rendering well. Basically if LVDS1 and LVDS2 were using different cards then this would be an issue. But since your output shows that both are on card0, then I don’t believe this is the issue. (More info on this Weston limitation here: https://gitlab.freedesktop.org/wayland/weston/-/issues/76)

I can only share a limited perspective from my side since the Toradex carrier boards I have only have connections for 1 LVDS display at a time. Meaning I can’t exactly mimic your setup. However I can hook up 1 HDMI display and 1 LVDS display to mimic a similar dual display setup like you have.

With this setup on my side if I run the Toradex Debian Weston container with no modifications I get Weston displaying on both displays. Furthermore outside of the container the graphical output from boot-up to Linux terminal is mirrored. This all to say that multiple display output should be possible, which means perhaps there is a different factor with your setup.

As a reference here’s what I have on my setup:

apalis-imx8-06738453:~$ ls /sys/class/drm
card0  card1  card1-HDMI-A-1  card1-LVDS-1  renderD128  renderD129  version

Also here’s my Weston logs as a reference: hdmi-lvds-weston.txt (18.2 KB)

Compared to yours I don’t see anything about atomic: couldn't commit new state: Invalid argument. Not sure why that is though. Other than the fact you’re using 2 LVDS compared to my 1 LVDS and 1 HDMI setup, we’re doing fairly similar use cases.

Looking at the datasheet for the Apalis i.MX8 I see that when using 2 LVDS displays, two different display controllers are used. Compared to my setup where 1 LVDS and 1 HDMI can be ran off a single display controller. I wonder if Weston also has issues with this, I’ll need to check.

Best Regards,
Jeremias

Greetings @jeremias.tx.

Thank you very much for your effort on this.

Since we are fully equipped with Toradex products, we will check if you can reproduce the weston logs by using the Toradex carrier board + Torizon + the containers mentioned above (having not connected the displays). Then, you could mimic the setup easily.

Since I am not available the next days, my colleague @Alias_Alias will post if this mimic setup will work. Further, we will do some researches about the line atomic: couldn't commit new state: Invalid argument - it’s great to have a reference point of a working setup. This line might focus our efforts on this issue.

We are looking forward to hear from you.
Your help is much appreciated!

Best,

Marcus

While you’re working on that I got some further info that may apply here. I spoke about your issue with some colleagues and they shared that the exact version of your Apalis i.MX8QM could matter.

To explain, on older versions of the i.MX8QM SoC from NXP there was a known errata/issue that caused LVDS instabilities. The newer versions of the Apalis i.MX8QM (1.1C and later) are built with a fixed version of the SoC. See the product page here for more details: High performance, low power Embedded Computing Systems | Toradex Developer Center

So with that said what version of the module are you working with?

Best Regards,
Jeremias

Hi @jeremias.tx ,

I still working on test on the ixora Board, but It seems possible to create the error on a normal ixora board. We have two Apalis i.MX8QM (1.1C) modules and have tested on these modules.

At the beging of the next week I share you an Idea how you can reproduce our error without display.

Best regards
Alias-Alias

Thank you for confirming that at least it’s not a hardware versioning issue. I’ll await steps for reproduction in the meantime.

Best Regards,
Jeremias

Greetings @jeremias.tx.

Thanks for waiting steps for reproduction in meantime.

@alias-alias and me, we have set up the following test settings to support you in reproducing the failures:

  1. First test setting: Using the Ixora Carrier Board (in our case V1.1A) without connecting any display device and starting container 3 (numbering as mentioned before). Since the output is similar to our custom carrier board, I have not printed the diff, here. In file “container_3_onIxoraBoard_display1_and_display2.txt”, you can find the corresponding logs.

  2. Second test setting: Using Ixora Carrier Board and one of your standard displays (type xyz), we have created an individual configuration for you using your standard display on LVDS-1 and one of our custom displays on LVDS-2 (device tree file “imx8-apalis-sensgit-v1.1.dts”). When starting this kind of variant of container 3, your standard display is intended to start. We think because of the same issue, your standard display won’t start, too. If you start the variant of container 1 (this starts LVDS-1 with your standard display configuration), you expect to see your standard display starting.

For comprehending, how we have created the containers for the second test setting, in the following you can find relevant steps. It’s just for completeness.

Command Collection:

On the host:

  • Download and install the TorizonCore Builder for your image

  • Checkout the device-trees

    • torizoncore-builder dt checkout
  • build the device tree

    • torizoncore-builder dt apply imx8-apalis-sensgit-v1.1.dts --include-dir
      device-trees/include --include-dir device-trees/dts-arm64/ --include-dir
      device-trees/include/dt-bindings/pinctrl/
  • Union it and deploy it

    • torizoncore-builder union dt_changes ; torizoncore-builder deploy
      –remote-host YOUR_IP --remote-username torizon --remote-password YOUR_PASSWORD–reboot

Now log in the device and type in the following commands:

  • Pull the docker- images

    • docker pull bdockeridsens/weston_d1
    • docker pull bdockeridsens/weston_d2
    • docker pull bdockeridsens/weston_dd
  • Start your working display

    • 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/tty7
      –user=torizon
  • Check the logs

    • docker logs weston
  • Stop the working weston container

    • docker stop weston
  • Start both displays (not working)

    • 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_dd:latest --developer weston-launch --tty=/dev/tty7
      –user=torizon
  • Check the logs

    • docker logs weston

Now you see nothing, because weston does not start correctly.

If you have any questions, please do not hesitate to ask. We are pleased to help.

Thank you very much for your support! It’s much appreciated.

Best,

Marcus

File Collection:

imx8-apalis-sensgit-v1.1.dts (4.0 KB)
container_3_onIxoraBoard_display1_and_display2.txt (19.3 KB)

Thank you very much for instructions I was able to reproduce with the following results:

  • Test 1: Ran the weston_dd container with the default Toradex device tree. LVDS display works
  • Test 2a: Ran the weston_d1 container with your device tree. LVDS display works
  • Test 2b: Ran the weston_dd container with your device tree. LVDS display no longer works.

With all that said it seems like I’m getting the same results as you are. However I did some experimenting and I noticed the following behavior. If I modify the weston.ini section such that LVDS-2 clones LVDS-1 like so:

[output]
name=LVDS-2
same-as=LVDS-1

Then I run bdockeridsens/weston_dd I now have weston displaying on my single LVDS screen, when it wasn’t before. I don’t know what happens on LVDS-2 since I can only connect a single LVDS display with my hardware. Can you check this on your side?

If this works and both LVDS-1 and LVDS-2 are displaying with cloned content this tells me that Weston can theoretically display content to two LVDS screens simultaneously. But perhaps the content needs to be cloned(?), or maybe there’s some other limitation here.

Best Regards,
Jeremias

Grettings @jeremias.tx .

Thanks for your testing and your results.
A small thing: The Test 1 should be done with our original device-tree from the first post. With this Device-Tree you create two drm outputs and then the container weston_dd does not work.

We are happy that the Test 2 works exectly how we think for you. That is great.

We now create two more containers. The weston.ini for the first (weston_dd_d1) is:

[core]
idle-time=0
require-input=false
xwayland=true
modules=screen-share.so
WESTON_DISABLE_ATOMIC=Y

[shell]
background-image=
background-color=0x00000000
panel-position=none
locking=false
allow-zap=false
num-workspaces=1

[keyboard]
vt-switching=false

[output]
name=LVDS-1
same-as=LVDS-2
mode=current
transform=flipped-rotate-90

[output]
name=LVDS-2
mode=current

The weston.ini for the second (weston_dd_d2) is:

[core]
idle-time=0
require-input=false
xwayland=true
modules=screen-share.so
WESTON_DISABLE_ATOMIC=Y

[shell]
background-image=
background-color=0x00000000
panel-position=none
locking=false
allow-zap=false
num-workspaces=1

[keyboard]
vt-switching=false

[output]
name=LVDS-1
mode=current
transform=flipped-rotate-90

[output]
name=LVDS-2
same-as=LVDS-1
mode=current

Please check the weston.ini files.
We will now check these two new containers on our hardware and tell you the results.

Thanks for your help.

Best regards,
Alias-Alias

Please do, I’m curious to know the effects the same-as property has on your displays. By the way I’m not sure if it was ever discussed but ultimately what is your goal here with the 2 displays?

Do you want to clone the same content on both displays? Have different content on each? Or extend the content from one display into the other?

Also I had another thought as well, what happens if you run weston_d1 and weston_d2 at the same time? Meaning 2 different weston clients that target/use one of the LVDS displays each.

Best Regards,
Jeremias

1 Like

Greetings @jeremias.tx.

Our objective:
In principle, we would like to flexibly show different content on each display. Let’s say this refers to one application per display at the same time (= starting two applications). Maybe it is even possible to run one app having two windows (one per display → starting one application)? We experienced the case of having one application per display to be the simple first step. Hence, right now, we focus on this.

So far, we have tested the following:

  • We are able to start either the first display with the aid of container (1) and show an application on this display or to start the second display with the aid of container (2) and show the application on that display.

  • We have successfully tested to start two applications, which are displayed the one display, which is currently started with container (1) or container (2). Hence, these containers are something like our controlling mechanism to make applications show up on a certain display.

  • So far, we have not been able to start two displays simultaneously on this imx8 (as a side note: on the imx6, this was tested successfully). Hence, we are not able to make tests about showing different content on each… Indeed, we are not sure how to handle this best. Ideally, we can decide for each application if it is either displayed on both displays (having different windows/viewers for instance) or this application is displayed only on one specific display.

Having two parallel weston containers running:
Regarding your idea to start two weston containers parallely, which is in our case container (1) and container (2). We already have tested this. We will create an individual post about test results, here.

weston.ini modification:
As @alias-alias has announced, I am going to issue the corresponding logs and tests in the next post.

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:

  1. Mirroring displays (weston.ini modification)

  2. 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.

  • Stop all weston containers

    • docker stop weston
    • docker stop weston2
  • Restart the first working conainer

    • 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 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

Thank you for reporting your findings. I did more testing/experimenting on my side and got some interesting results.

So first of all I did tests using the new containers you created. I had a similar setup as before using the device tree you supplied. However this time I did not get the same results as you observed.

  • Using container weston_dd_d1 I did get a weston display on my single LVDS screen
  • Using container weston_dd_d2 I also got a weston display on my single LVDS screen.

This seems contrary to your observations. I’m not quite sure why other than your setup actually has 2nd lvds screen attached. As for the logs for these containers I didn’t see the atomic.. or the repaint-flush messages.

I was a bit at a dead end for why we’re getting different results with these new containers. So I decided to approach the problem from a different angle. In your device tree I’ve noticed you made all your changes to the ldb2 interfaces. However there is a ldb1 interface on i.MX8. With this I decided to experiment with adding the 2nd LVDS on ldb1 instead of ldb2. In the end my changes ended up looking like this: (I just modified the existing dts/dtsi files rather than create a new one)

diff --git a/dts-arm64/imx8-apalis-v1.1.dtsi b/dts-arm64/imx8-apalis-v1.1.dtsi
index 3a97069..834679d 100644
--- a/dts-arm64/imx8-apalis-v1.1.dtsi
+++ b/dts-arm64/imx8-apalis-v1.1.dtsi
@@ -40,6 +40,19 @@
                };
        };
 
+        panel_lvds2: panel-lvds2 {
+                compatible = "panel-lvds";
+                backlight = <&backlight>;
+
+                status = "okay";
+
+                port {
+                        panel_lvds_in2: endpoint {
+                                remote-endpoint = <&lvds2_out>;
+                        };
+                };
+        };
+
        pcie_sata_refclk: sata-clock-generator {
                compatible = "fixed-clock";
                #clock-cells = <0>;
@@ -1255,6 +1268,31 @@
        };
 };
 
+&ldb1 {
+        status = "okay";
+
+        lvds-channel@0 {
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                fsl,data-mapping = "spwg";
+                fsl,data-width = <24>;
+                status = "okay";
+
+                port@1 {
+                        reg = <1>;
+
+                        lvds2_out: endpoint {
+                                remote-endpoint = <&panel_lvds_in2>;
+                        };
+                };
+        };
+};
+
+&ldb1_phy {
+        status = "okay";
+};
+
 /* Apalis SPI1 */
 &lpspi0 {
        pinctrl-names = "default";

Not included in the above diff I also enabled the ldb2 interfaces and panel-lvds2 uses the same timings as panel-lvds. Not that this matters much since I can only connect 1 LVDS display.

I deployed these device tree changes to my board and got promising results. I ran weston_dd same as before but now with my device tree. This time I did get weston display output on my single LVDS display. This is unlike before with your device tree where weston_dd didn’t work for me. See my weston logs for this test here: logs.txt (9.4 KB)

In the logs you can see a LVDS-1 and LVDS-2 are recognized however there’s no atomic or repaint-flush method as before.

So in summary perhaps trying to implement something similar to my device tree changes above could help your situation.

Best Regards,
Jeremias

Greetings @jeremias.tx .

We will take your approach and build such a device-tree with &ldb1 and &ldb2. For some comparison, it would be nice if you share the complete device-tree and not just the GIT diff. If possible, please upload the complete device-tree here.

We will post our results of this new device-tree with &ldb1 and &ldb2 here. We are very optimistic, because that kind of device-tree we have not tried before.

Best regards
Alias-Alias

I’ve attached the modified device tree file here: imx8-apalis-v1.1.dtsi (45.8 KB)

It really doesn’t have any further information outside of what the diff shows. The rest of the file is un-modified as it appears in the linux-toradex kernel source. The only thing you would need to do differently is add your display’s timings to the panel-lvds2 node. Finally, I enabled the ldb2 nodes using device tree overlays.

Best Regards,
Jeremias

1 Like

Greetings @jeremias.tx.

Thank’s for your dts file and your great idea of using ldb1 (being configured with pins 61 - 91; LVDS0_CH0_) and ldb2 (being configured with pins 246 - 302; LVDS1_A_ and LVDS1_B_*).

Having tested this, we have been able to reproduce your results using LVDS_1 (ldb2 ; LVDS1_A_) and LVDS_3 (ldb1 ; LVDS0_CH0_).
So far, we have used LVDS_1 (ldb2 ; LVDS1_A_) and LVDS_2 (ldb2 ; LVDS1_B_) only. Hence, this is a success and I am going to declare this topic as a solution!

Here, you can find a visual impression having a weston on both displays and an application running on the smaller display:

:grinning:

Since we have used touch at LVDS_2, now, touch is not working any more.
Here, we are faced with the problem of activating i2c_6 instead of i2c_2, which is kind of complicated at imx8. As this is not part of this topic, we have created another topic, which you can find here.

Although LVDS_1 and LVDS_3 nicely start both displays (see figure presented above), we have not been able to start the two displays using LVDS_1 and LVDS_2. Regrettably, this is our preferred configuration because the imx6 can do this. Here, only one display can be used and the other remains black at our preferred configuration. Hence, our last question regarding this topic is:

Is it possible to use ldb1 with different pins, such as the pins from LVDS_1 (ldb2 ; LVDS1_A_*)?

As our initially posted weston logs of our preferred configuration indicate errors about ldb2, it might be, that this is a ldb-related issue… Maybe you can have an internal check on this…?

If you find an issue on this and you are going to create an update here, it was great if you just can reply to this. Of course, we are going to test this and post test results, here.

However, we have an alternative configuration by using LVDS_1 and LVDS_3.

Thank’s a lot for your support.

Best,

Marcus

I’m glad I could help out!

Thank you for your patience, it really does take us quite a bit more time to reproduce the more unique display setups.

Unfortunately I don’t believe this is trivially possible. The pins themselves aren’t configurable via device tree. Also the exact assignments seem to depend on the physical connections in the SoC itself.

Best Regards,
Jeremias

Greetings @jeremias.tx

For your interest, meanwhile, we have been working on some videos in order to show our product we are aiming for. In the recent six years, we have been using Toradex components because of their characteristics and great community support for creating the most innovative guitar that, to the best of our knowledge, currently exists. We call it SensGuitar.

For a quick overview, check out our 1-minute-teaser-video.

The most exciting details of our SensGuitar:

  • An ultra-wide, full-color display incorporated into the fretboard of the guitar neck.
  • A touch display embedded in the guitar body
  • FPGA computer-based sound processing (including simulated effects devices)
  • Feedback from and novel interaction possibilities with the SensGuitar
  • Built-in mobile studio with 12 flexibly configurable audio inputs/outputs
  • Modular expandability/upgradability.

We would like to show the prototype of this guitar to the world on Kickstarter on 03/15/2022, build a community for technicians, guitarists and maker, so that we do not only inspire guitarists. Our intended goal with the campaign is to open source this as a market-ready guitar and all of the IT components we have developed for this purpose, if funding comes through the campaign. You can find it at the
kickstarter-page.

However, this is not an advertising rather than a thank you Toradex and @jeremias.tx for your great support at this community.

Many greetings

Marcus