meta-flutter imx8mm

[munoz0raul]

Hi, I just update all my meta to the latest kirkstone and the flutter gallery is not working anymore on the imx8mm.

This is the error:

root@imx8mm-lpddr4-evk:/var/rootdirs/home/fio# flutter-auto --b=/usr/share/flutter/gallery/3.7.7/release/
[INFO:main.cc(85)] agl @ 98c8215
[INFO:configuration.cc(295)] **********
[INFO:configuration.cc(296)] * Global *
[INFO:configuration.cc(297)] **********
[INFO:configuration.cc(298)] Application Id: .......... flutter-auto
[INFO:configuration.cc(302)] Cursor Theme: ............ 
[INFO:configuration.cc(303)] Disable Cursor: .......... false
[INFO:configuration.cc(305)] Debug Backend: ........... false
[INFO:configuration.cc(307)] ********
[INFO:configuration.cc(308)] * View *
[INFO:configuration.cc(309)] ********
[INFO:configuration.cc(316)] Bundle Path: .............. /usr/share/flutter/gallery/3.7.7/release/
[INFO:configuration.cc(317)] Window Type: .............. NORMAL
[INFO:configuration.cc(318)] Output Index: ............. 0
[INFO:configuration.cc(320)] Size: ..................... 1920 x 720
[INFO:configuration.cc(325)] Fullscreen: ............... false
[INFO:configuration.cc(327)] Accessibility Features: ... 0
[INFO:display.cc(315)] Keyboard Present
[INFO:engine.cc(577)] (0) Loading AOT: /usr/share/flutter/gallery/3.7.7/release//lib/libapp.so
[INFO:navigation.cc(32)] (0) Navigation: Select Single Entry History
[INFO:navigation.cc(55)] (0) Navigation: Route Information Updated
    location: /
    state: 
    replace: 0
zwp_linux_surface_synchronization_v1@20: error 5: wl_surface@13 no buffer for synchronization
EGL: errno=71 (Protocol error)

Any idea what that could be?

[X-Terminator]

We are experiencing the same issue with flutter-auto on our custom iMX8M Nano board. We are able to run flutter applications using flutter-pi (using DRM) and flutter-client (with Wayland + Weston), but when running an application using flutter-auto we get the same error message:

flutter-auto --d --f --b=/usr/share/flutter/animated_background_example/3.7.7/release/
[INFO:main.cc(85)] agl @ 98c8215
[INFO:configuration.cc(295)] **********
[INFO:configuration.cc(296)] * Global *
[INFO:configuration.cc(297)] **********
[INFO:configuration.cc(298)] Application Id: .......... flutter-auto
[INFO:configuration.cc(302)] Cursor Theme: ............
[INFO:configuration.cc(303)] Disable Cursor: .......... false
[INFO:configuration.cc(305)] Debug Backend: ........... true
[INFO:configuration.cc(307)] ********
[INFO:configuration.cc(308)] * View *
[INFO:configuration.cc(309)] ********
[INFO:configuration.cc(316)] Bundle Path: .............. /usr/share/flutter/animated_background_example/3.7.7/release/
[INFO:configuration.cc(317)] Window Type: .............. NORMAL
[INFO:configuration.cc(318)] Output Index: ............. 0
[INFO:configuration.cc(320)] Size: ..................... 1920 x 720
[INFO:configuration.cc(325)] Fullscreen: ............... true
[INFO:configuration.cc(327)] Accessibility Features: ... 0
            EGL_KHR_fence_sync, EGL_KHR_reusable_sync, EGL_KHR_wait_sync,
            EGL_KHR_image, EGL_KHR_image_base, EGL_KHR_image_pixmap,
            EGL_KHR_gl_texture_2D_image, EGL_KHR_gl_texture_cubemap_image,
            EGL_KHR_gl_renderbuffer_image, EGL_EXT_image_dma_buf_import,
            EGL_EXT_image_dma_buf_import_modifiers, EGL_KHR_lock_surface,
            EGL_KHR_create_context, EGL_KHR_no_config_context,
            EGL_KHR_surfaceless_context, EGL_KHR_get_all_proc_addresses,
            EGL_EXT_create_context_robustness, EGL_EXT_protected_surface,
            EGL_EXT_protected_content, EGL_EXT_buffer_age,
            EGL_ANDROID_native_fence_sync, EGL_WL_bind_wayland_display,
            EGL_WL_create_wayland_buffer_from_image, EGL_KHR_partial_update,
            EGL_EXT_swap_buffers_with_damage, EGL_KHR_swap_buffers_with_damage,
            EGL_EXT_pixel_format_float
[INFO:engine.cc(577)] (0) Loading AOT: /usr/share/flutter/animated_background_example/3.7.7/release//lib/libapp.so
[INFO:navigation.cc(32)] (0) Navigation: Select Single Entry History
[INFO:navigation.cc(55)] (0) Navigation: Route Information Updated
        location: /
        state:
        replace: 0
zwp_linux_surface_synchronization_v1@18: error 5: wl_surface@12 no buffer for synchronization
EGL: errno=71 (Protocol error)
EGL: errno=71 (Protocol error)
[ERROR:/usr/src/debug/flutter-auto/git-r0/git/shell/backend/egl.cc(98)] Make current failed: 12294
[ERROR:/usr/src/debug/flutter-auto/git-r0/git/shell/backend/egl.cc(123)] SwapBuffers failed: 12289

The linux version from NXP we are using is 5.15.32, which uses Wayland 1.20.0 and Weston 10.0.0. Could there be a compatibility issue between this version of Wayland/Weston and flutter-auto?

P.S. This issue seems to be the same as: https://github.com/meta-flutter/meta-flutter/issues/275

[jwinarske]

@munoz0raul not of the top of my head. I will take a look at trying to repro on a different target next week (currently in Japan). Also I have a lot of changes queued up for the next OSS release.

@X-Terminator it would help to repro on a device I have. I don't have any iMX boards capable of flutter at this time

[jwinarske]

@munoz0raul @X-Terminator I just ordered a Boundary Devices imx8mm device - $315 US personal. I will have it late next week.

[jwinarske]

@munoz0raul @X-Terminator

I just pulled down the kirkstone manifest :

<manifest>

  <default sync-j="4" revision="kirkstone"/>

  <remote fetch="https://git.yoctoproject.org/git" name="yocto"/>
  <remote fetch="https://github.com/Freescale" name="freescale"/>
  <remote fetch="https://github.com/openembedded" name="oe"/>

  <project remote="yocto" name="poky" path="sources/poky"/>
  <project remote="yocto" name="meta-freescale" path="sources/meta-freescale"/>

  <project remote="oe" name="meta-openembedded" path="sources/meta-openembedded"/>

  <project remote="freescale" name="fsl-community-bsp-base" path="sources/base">
    <linkfile dest="README" src="README"/>
    <linkfile dest="setup-environment" src="setup-environment"/>
  </project>

  <project remote="freescale" name="meta-freescale-3rdparty" path="sources/meta-freescale-3rdparty"/>
  <project remote="freescale" name="meta-freescale-distro" path="sources/meta-freescale-distro"/>
  <project remote="freescale" name="Documentation" path="sources/Documentation"/>

</manifest>

In the tree I see weston_10.0.2.bb, and weston_10.0.1.imx.bb.

Which BSP, and weston are you both using?

I also heard today from AGL maintainer there is a compositor bug with fsl community BSP that AGL+Collabora have not yet had time to triage.

[X-Terminator]

Hello @jwinarske , thanks for having a look at this.

At our site we are using the weston_10.0.0.imx.bb recipe with the imx-nxp-bsp NXP BSP (based on the imx-5.15.32-2.0.0.xml manifest).

Our distro is based on fsl-imx-wayland.conf and our custom iMX8M Nano board uses a machine config that is derived from imx8mn-ddr4-evk.conf.

[jwinarske]

@X-Terminator thanks for the info. My HDMI adapter board will be here next week. I'll focus on tip of tree kirkstone first.

@munoz0raul can you provide similar info?

[jwinarske]

I have a repro on my Boundary Devices Nitrogen8M Mini SBC. The issue is related to synchronization and frame callbacks. Looks like imx weston wants something particular. I should have progress by Friday or next Monday.

[munoz0raul]

Sorry about the delay.

I finally found some time to set up the same environment on my table.

I'm using the manifest from our Linux microPlatform: https://github.com/foundriesio/lmp-manifest/tree/715d3c48bde0c0c1f5fd7b7e5c91eaf91725528d

The version I have is based on bsp 6.1-1.0.x-imx and is running:

libweston-11-0 11.0.1.imx-r0
packagegroup-core-weston 1.0-r1
weston 11.0.1.imx-r0
weston-examples 11.0.1.imx-r0
weston-init 1.0-r0
weston-xwayland 11.0.1.imx-r0
wayland 1.22.0.imx-r0
wayland-utils 1.0.0-r0
xwayland 23.1.1.imx-r0

And here is the thing same layers with meta-flutter on: 4e8950a3a6aa203723436b8718a29040a0c537f2 works fine.

If I update meta-flutter to latest e08c45c6b8c961734e7be9745e0f1ea344fa5ea8 I have this error:

flutter-auto --b=/usr/share/flutter/gallery/3.10.5/release/
[INFO:main.cc(85)] agl @ 7b79ed6
[INFO:configuration.cc(295)] **********
[INFO:configuration.cc(296)] * Global *
[INFO:configuration.cc(297)] **********
[INFO:configuration.cc(298)] Application Id: .......... flutter-auto
[INFO:configuration.cc(302)] Cursor Theme: ............ 
[INFO:configuration.cc(303)] Disable Cursor: .......... false
[INFO:configuration.cc(305)] Debug Backend: ........... false
[INFO:configuration.cc(307)] ********
[INFO:configuration.cc(308)] * View *
[INFO:configuration.cc(309)] ********
[INFO:configuration.cc(316)] Bundle Path: .............. /usr/share/flutter/gallery/3.10.5/release/
[INFO:configuration.cc(317)] Window Type: .............. NORMAL
[INFO:configuration.cc(318)] Output Index: ............. 0
[INFO:configuration.cc(320)] Size: ..................... 1920 x 720
[INFO:configuration.cc(325)] Fullscreen: ............... false
[INFO:configuration.cc(327)] Accessibility Features: ... 0
[INFO:display.cc(317)] Keyboard Present
[INFO:engine.cc(577)] (0) Loading AOT: /usr/share/flutter/gallery/3.10.5/release//lib/libapp.so
[INFO:navigation.cc(32)] (0) Navigation: Select Single Entry History
[INFO:navigation.cc(55)] (0) Navigation: Route Information Updated
    location: /
    state: 
    replace: 0
zwp_linux_surface_synchronization_v1@20: error 5: wl_surface@13 no buffer for synchronization
EGL: errno=71 (Protocol error)
EGL: errno=71 (Protocol error)
warning: queue 0x557fc63760 destroyed while proxies still attached:
  wl_callback@31 still attached
  wl_callback@30 still attached
  wl_callback@29 still attached
  zwp_linux_buffer_release_v1@28 still attached
  zwp_linux_surface_synchronization_v1@20 still attached
  wl_viv@14 still attached
  zwp_linux_buffer_release_v1@27 still attached
  wl_callback@23 still attached
  zwp_linux_buffer_release_v1@25 still attached
  zwp_linux_buffer_release_v1@22 still attached

[jwinarske]

@munoz0raul have you ever tried just the home screen recipe? It doesn't have Marius's (AGL) commits. It's the release from our internal repo.

[munoz0raul]

Hi @jwinarske I can give it a try, can you send me more details where I can find it?

[jwinarske]

@munoz0raul @X-Terminator @

Update on my end. I am playing around with pending OSS release with last nights 3.10.6 meta-flutter, and I am seeing what looks like a race condition. I instrument log output for each wayland commit call.

This fails immediately

homescreen --b=/usr/share/flutter/gallery/3.10.6/release 

This fails at different times, which is different for each run.

WAYLAND_DEBUG=all homescreen --b=/usr/share/flutter/gallery/3.10.6/release 

If I run it fullscreen with WAYLAND_DEBUG set for verbose, it will randomly run until the mouse is bumped. One case it ran for minutes. This is with imx-weston.

It's pretty clear imx-weston has a bug.

[mv0]

Fyi, it is highly suspicious that when setting up the WAYLAND_DEBUG to cause those kind of behaviours. All my fingers point rather to the driver (vivante, EGL) than the custom weston-imx fork. But I can't rule that out entirely, being a NXP modified version of weston.

The other issue has some wayland traces where it shows that there's commit without actually attaching a wl_buffer to the surface, with the previous ones being handling correctly. I speculate that those actually are handling by eglSwapBuffers (which is driver-specific). I suspect that the buffer is busy at the time, with the driver scheduling another frame callback but without providing (maybe?) a new buffer when this happens. @jwinarske I don't think you're explicitly handling that right? (we do use EGL in flutter-homescreen...?)

It looks this was pulled in when updating to kirkstone? Any possibility to rule flutter-auto and see if we can switch back somehow? While this is quite likely a weston-imx/NXP issue, we should try to at least rule out flutter-auto.

Finally, is there a possibility to use the mesa version and upstream weston? We could also rule flutter-auto that way, assuming it is possible to run the open source stack on those boards?

[jwinarske]

@mv0 Thanks for jumping in :)

Things worked here: https://github.com/toyota-connected/ivi-homescreen/commit/20df3c8a976ee623f1d6d35a66390591ae061bd5

Which is quite a few changes back. When I enable WAYLAND_DEBUG the time to error is clearly related to first mouse move. Sometimes one frame is rendered, sometimes twenty, sometimes many more, and even sometime more with mouse movement. Hence the statement of a race condition.

The other issue has some wayland traces where it shows that there's commit without actually attaching a wl_buffer to the surface, with the previous ones being handling correctly. I speculate that those actually are handling by eglSwapBuffers (which is driver-specific). I suspect that the buffer is busy at the time, with the driver scheduling another frame callback but without providing (maybe?) a new buffer when this happens. @jwinarske I don't think you're explicitly handling that right? (we do use EGL in flutter-homescreen...?)

The error I'm seeing consistently in my test build + imx weston combo is "no buffer for synchronization". The engine makes EGL calls independent of weston commit calls. I am not tracking any of these. The on frame callback for base surface and sub surfaces call commit. Non-issue on all targets except imx.

[mv0]

Things worked here: toyota-connected/ivi-homescreen@20df3c8

Did you just checkout that SHA1? Is that the first working commit? Did you bisect it? If this happens with the latest kirkstone and it works with that commit, probably there's something in main/master that doesn't play nice (with the driver?). We had some reports a while back that input wasn't being delivered to surfaces if the application was creating and managing multiple surfaces at the same time. That only happened with proprietary driver stack.

The engine makes EGL calls independent of weston commit calls.

Yeah, that's I remember, with the EGL backend. But with OSS 0223 and OSS 042023, particularly OSS 0223, quite a few things landed by the looks of it. :shrug: doesn't help that these are piled up in huge chunks. If possible maybe we can identify what caused it (indirectly that is) assuming that someone can actually point NXP folks at it to fix it. Otherwise, I don't see what we can do about it.

[jwinarske]

@FranzForstmayr @munoz0raul @X-Terminator

Try this patch, it works for me: 0001-Disable-on_frame_base_surface-wl_surface_commit.zip

[X-Terminator]

@jwinarske thanks for your continued support.

I have applied the patch to both flutter-auto (SRCREV = 98c82158c5ad48220393b39e3cb8206b08166f99) and ivi-homescreen (SRCREV = 52f2bf67abf3d3b39ed89bae49bdceec99b4888c) and with this patch the application no longer crashes on our board :).

However there now seem to be a couple of other issues that occur:

First, we are running our flutter application as a non-root user (same user that runs weston). This user does not have a HOME directory. When running flutter-auto or homescreen as this user we get the following error:

libc++abi: terminating with uncaught exception of type std::__1::__fs::filesystem::filesystem_error: filesystem error: in create_directories: Read-only file system ["//.flutter-auto"]

We can work around this for now by adding Environment=HOME=/tmp/ to the service file that launches the application. This allows the /tmp/.flutter-auto or /tmp/.homescreen directory to be created and enables the application to start up. Is there any way we can disable the need for the creation of these files?

The second (bigger) problem is that we now see a lot of flickering in certain parts of our application. We see it mostly when the application transitions to a different screen and in areas where we have animations on the screen. This flickering also occurs in the flutter-gallery application (where it mostly occurs when moving the mouse around) and in this application we also see rendering issues where sometimes parts of the screen are repeated at other locations on the screen. We do not see this behavior with the flutter-client or flutter-pi embedders. Are there any configuration options we could try turning on/off to try to eliminate this flickering behaviour?

[jwinarske]

@X-Terminator

1. Having HOME set to a writable location is required. If you have a squashfs (RO) implementation, then pointing HOME to /tmp is the right solution. The downside would be that you cannot leverage caches to decrease application startup time.
2. The flickering is an engine regression that came in when dirty region management support was pulled in, and it also indicates you are running Flutter version > 3.3.7. meta-flutter has support for >3.10.5 for SDK + engine. I have homescreen/flutter-auto running on 3.10.6 without flickering. The OSS commits for homescreen/flutter-auto will happen within a week. AGL migration to 3.10.6 will start in two weeks. One workaround is to move back to 3.3.x (AGL is on 3.3.7).

[jwinarske]

@X-Terminator I moved your comment to a new issue.

[emanuel-th]

Hi, we use a i.MX6QP/Q/DL, switched to kirkstone recently and see the same error for simple flutter apps. The fix also works for us. We currently use flutter SDK 3.10.6.