cppSlint/rustSlint failed to show application on screen on imx6ull

[andreriesco]

Release log, but also on debug it did not show the application on screen:

 ✔ Container torizon-autotests260arm-1  Created                                                                                            11.5s 
Attaching to autotests260arm-1
autotests260arm-1  | slint linuxkms backend: unrecognized renderer skia, falling back default
autotests260arm-1  | Hello Torizon!
autotests260arm-1  | Using Skia OpenGL renderer
autotests260arm-1  | Rendering at 800x480
autotests260arm-1  | thread '<unnamed>' panicked at api/cpp/lib.rs:64:6:
autotests260arm-1  | called `Result::unwrap()` on an `Err` value: OtherError("Error adding gbm buffer as framebuffer: invalid argument")
autotests260arm-1  | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
autotests260arm-1 exited with code 132

The board used was a Colibri IMX6ULL, which does not have a GPU.

[andreriesco]

On rustSlint the following error happened:

autotests260arm-1  | slint linuxkms backend: unrecognized renderer skia, falling back default
autotests260arm-1  | Hello Torizon!
autotests260arm-1  | Using FemtoVG OpenGL renderer
autotests260arm-1  | Rendering at 800x480
autotests260arm-1  | Error: OtherError("Error adding gbm buffer as framebuffer: invalid argument")
autotests260arm-1 exited with code 1

[andreriesco]

@tronical, do you know what may be the issue?

[tronical]

I have an idea. At least for rustSlint I see one issue. I'll make a PR for next today.

[microhobby]

@tronical don't worry, this was a test environment issue, it's not reproducible.

[tronical]

The output indicated the use of OpenGL (which is weird, that should fail), but more importantly, for rustSlint it indicated the use of the wrong renderer. I've made https://github.com/toradex/vscode-torizon-templates/pull/246 to address that.

[microhobby]

@tronical I'm reopening this since it's reproducible on imx6ull even with the changes from #246 applied. As pointed by @andreriesco the imx6ull does not have GPU, but even using export SLINT_BACKEND=linuxkms-skia-software results in the same output.

[tronical]

What should happen on the ULL is that Slint drops gbm usage and falls back to software rendering into drm dumb buffers. It seems almost as if the system claims to have EGL gbm support, but doesn't when it's too late. Could you try something for me and change the SLINT_BACKEND=linuxkms-skia line in the docker file to say SLINT_BACKEND=linuxkms-skia-software ?

(This would not be a fix, but it would help to diagnose)

[tronical]

Are you sure that the output is exactly the same?

What's the docker base image for the ULL? I have the feeling that there may be a setup problem in that the system claims to support EGL, when in fact it doesn't.

That said, I don't think that this is a regression. I've got a ULL in our office, but I don't think that I'll get around to trying it in the next 3ish weeks.

Unless the ULL is a particular target for this new release I suggest to accept this as known issue for now.

[microhobby]

@tronical yeah agreed to set it as a known issue. Also, I'm repeating the flow here in a fresh environment to ensure I'm not making any mistakes in setting the env variable, because is weird. I'll keep you posted, thanks.

[microhobby]

@tronical confirmed that was an issue in the previous environment. Setting the SLINT_BACKEND=linuxkms-skia-software on Dockerfile works, the application is shown in the screen.

[tronical]

Ok, great. Then I just need to get my hands on a device to see how we can reliably detect that the device does in fact not support gbm. (This would be a workaround to deploy inside Slint)

[microhobby]

@tronical no need to rush, we are only making sure that it is running ok on all devices that support Torizon.