App get stuck after launch

[munoz0raul]

Hello, I'm writing it here because maybe you could give me some tips on how to get more information about my problem.

I was able to test flutter with mesa and Wayland inside a container. Everything was working but without Hardware acceleration (Vivante libraries).

My second test was trying to add the Vivante libraries inside the container. I manage to build and launch the app, but it got stuck. I don't really know if touch/input is not working or if the app is stuck.

Finally, I tried the Yocto meta-flutter for iMX8. This build worked well and I was also able to launch the gallery. Looks like I got the same problem from the container with Vivante. Apps go up but I get stuck.

Here is the app log (the same log I'm getting in the container as well)

root@imx8mm-var-som-symphony:/var/rootdirs/home/fio# LC_ALL=en_US.UTF-8 FLUTTER_LOG_LEVELS=TRACE WAYLAND_USER="root" XDG_RUNTIME_DIR="/run/user/63" WAYLAND_DISPLAY="wayland-0" DISPLAY=":0" flutter-client -b /var/rootdirs/home/fio/share/gallery/build/linux/arm64/release/bundle 
[TRACE][elinux_window_wayland.cc(144)] presentation info: clk_id = 1
[INFO][elinux_window_wayland.cc(466)] Display output info: width = 800, height = 480, refresh = 67734
[TRACE][elinux_window_wayland.cc(972)] Created the Wayland surface: 1280x720

https://user-images.githubusercontent.com/7702208/136465119-b05f102d-578a-4fb8-bec1-822628bacd11.mp4

Please, any suggestion on how to get more information? Is there any other library necessary for the input/touch to work with flutter? Any tips I really appreciate.

[HidenoriMatsubayashi]

Looks like I got the same problem from the container with Vivante

I'm not sure about your environment. Why do you use a container, and does your flutter app work in the container on imx8m? Can you try the same thing without the container first?

[munoz0raul]

The Container with mesa packages works fine.

The Container with Vivante packages doesn't work.

Yocto builds but the application also gets stuck.

I think you are right, let me try to make the yocto work to make sure what work or not.

In the Yocto, I just add the package: flutter-wayland-client

On my device, I can see the flutter-client binary but flutter-elinux is not available there.

What would be the best way to create a distribution with the fluttler-wayland-client + gallery application?

[HidenoriMatsubayashi]

You are creating a docker container, which is to build and develop software for your target devices (arm64). Is my understanding correct? I'm afraid that I'm not sure why do you don't use NXP BSP (Yocto) on your target devices?

The Container with Vivante packages doesn't work.

Also, vivante is the GPU driver for i.MX 8M platforms. Are you creating your original linux destribution for i.mx 8m platforms? Which are you creating build-environment or target rootfs? Could you share the thing you want to do?

[munoz0raul]

I'm doing everything thing in the device!

I'm running docker build docker run in the device.

I also tested yocto but i don't know how to build the gallery app in the yocto.

[HidenoriMatsubayashi]

I also tested yocto but i don't know how to build the gallery app in the yocto.

I think that there are some ways. Let's say, building in the Yocto (in this case, we need to create a new Yocto recipe to build your app in the Yocto), cross-building using Yocto SDK, cross-building using flutter-elinux and the target's rootfs, and so on.

[devmil]

Hi. Were you able to solve this? I have the exact same behavior in an lxc based container environment on an IMX.8 device with Vivante libraries

[HidenoriMatsubayashi]

Information such as whether the app is frozen or just inputs cannot be accepted can help solve the problem.

[devmil]

Hi,

I tried to analyze what's going on a little bit deeper but hadn't too much time yet.

What I already know:

1. If I launch the default Counter Flutter App I can see the initial screen and it seems to be stuck.
2. If I launch a little bit more complicated application (just a timer and a Confetti package in use) then it doesn't even show the initial screen content but only a white screen

When activating Wayland debugging (WAYLAND_DEBUG=1) then I can see that the application is running and trying to update the screen.

So my current assumption is that the Weston Server somehow gets stuck. Either by the initial feature configuration or by the Vivante specific OpenGl usage. But that are only assumptions.

Here is the log I get from the more complex application: 2022-01-26-flapp-complex-start.txt And here is the log I get from the simple application: 2022-01-26-flapp-simple-start.txt

[psstoyanov]

Does the same behaviour happen when using different Wayland compositor? cage for example

Note: Haven't figured out how to use Yocto with Pico-Pi i.MX7D yet to attempt to replicate with similar setup.

[devmil]

I found the "rendering" issue. I was not aware of the usage of sizes in Flutter. I tried to do absolute positioning and by being scaled up the content of the screen I ended up seeing was a portion of the white background. => everything is fine in terms of rendering!

Touch is still not working but I will look into that now. (the touch is transmitted via wayland as I can see the touch interaction in the logs but it doesn't reach Flutter)

Sorry for the confusion.

[devmil]

Touch also works -> touch rotation issue on our test setup and the fact that touch_indicator doesn't work in this setup. So Flutter elinux is working here for now! Thanks for all your effort!

[munoz0raul]

Hi @devmil, could you share what you did to make it work? I stopped working on it, but I want to get back to it soon.

[devmil]

I can try to do so. I'm not deeply involved in the Weston side (this is an internal deliverable). I think it would be best to ping me via email.

Because there is not much I did to get from "seems to be stuck" to "is working" as it has been basically working before I just was not able to see it :)

You could enable Wayland logging by setting WAYLAND_DEBUG=1 to see if the touch events are reaching your application.

The only thing I had to change was to set ENABLE_EGL_ASYNC_BUFFER_SWAPPING in the embedder back to OFF (this is the default) because when this is enabled the application really got stuck (I enabled this in the course of changing different parameters to narrow down my phantom problem). Maybe updating the Embedder already solves your problem (this define was introduced after this issue has been created, #235 )

[HidenoriMatsubayashi]

I'll close this issue.

Just FYI. I've already removed ENABLE_EGL_ASYNC_BUFFER_SWAPPING and added --async-vblank option (default disable, see #363 for the details) instead.