Test on arm devices

[HidenoriMatsubayashi]

This issue is a memo for testing on different arm devices. I would like to test on a lot of arm devices.

Tested devices

• Jetson Nano (OS: Ubuntu 18.04, JetPack)

  • Wayland backend
  • DRM backend (Support EGLStream #1)

• Raspberry Pi4 (OS: Ubuntu 20) Doesn't work on Raspberry Pi4 when using DRM backend #9

  • Wayland backend
  • DRM backend

• i.MX 8M Mini EVK (OS: Zeus, imx-5.4.70-2.3.1.xml)

  • Wayland backend
    DRM backend NXP doesn't support EGL for GBM.

• RB5 (OS: Based Ubuntu 18.04)

  • DRM-GBM backend
    Wayland backend Weston version is 3.0 and it doesn't support xdg-shell

[HidenoriMatsubayashi]

@Mai-Matsuura Could you try testing on Raspberry Pi4?

Yes, I will try it.

[psstoyanov]

Observations from my devices:

• PinePhone (Allwinner A64) and PinebookPro (rk3399) both running ManjaroARM with kernel 5.11 and their respective open source driver:
  • drm backend doesn't work on either system (different errors are being produced)
  • running the wayland client works provided the app is running within a Weston environment. Using plasma wayland/ plasma mobile/ wlroots based environment results in the same error: [ERROR][linuxes_window_wayland.cc(627)] Invalid compositor and shell.

Currently I can't verify on my desktop system using RX6800 (main desktop environment - Plasma Wayland). For whatever reason the Dart VM snapshot version doesn't match:

./flutter-drm-backend sample_2/build/linux/x64/release/bundle           
amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)
amdgpu: amdgpu_device_initialize failed.
[ERROR][context_egl.h(95)] Failed to create EGL off-screen surface.(eglGetError: EGL_BAD_ALLOC)
[ERROR][linuxes_surface_gl_drm.h(50)] Off-Screen surface is invalid.
[ERROR][native_window_drm.cc(89)] TODO: implement here!!
[ERROR][flutter_linuxes_view.cc(60)] Failed to change surface size.
[ERROR][native_window_drm.cc(311)] Unsupported cursor: 
[ERROR][native_window_drm.cc(176)] Could not move the mouse cursor: -13
[ERROR][native_window_drm.cc(130)] Failed to set cursor buffer. (-13)
[FATAL:flutter/runtime/dart_vm_initializer.cc(22)] Error while initializing the Dart VM: Wrong full snapshot version, expected '39a9141bbcc3cae43e6f9f6b7fbaafe3' found 'aac992673ad0e4a5e41716d2a9911c88'
[1]    171859 abort (core dumped)  ./flutter-drm-backend sample_2/build/linux/x64/release/bundle

[HidenoriMatsubayashi]

Thank you for your comment.

[FATAL:flutter/runtime/dart_vm_initializer.cc(22)] Error while initializing the Dart VM: Wrong full snapshot version, expected '39a9141bbcc3cae43e6f9f6b7fbaafe3' found 'aac992673ad0e4a5e41716d2a9911c88'
[1]    171859 abort (core dumped)  ./flutter-drm-backend sample_2/build/linux/x64/release/bundle

The first problem is that the Flutter SDK and Engine (libflutter_engine.so) versions don't match. Could you re-build Flutter Engine (libflutter_engine.so) with the same version using in the Flutter SDK you are using? Flutter SDK specifies the version of Flutter Engine in ${INSTALL_PATH}/bin/internal/engine.version.

But I need to update README.

[psstoyanov]

Thank you for the information! This makes it a lot easier to verify if the correct versions are in use.

The issue on my x64 machine could lie somewhere else as the versions are indeed matching 🤔 I will clean and update my setup later today to ensure there are no lingering caches remaining. I've already thoroughly cleaned the Flutter SDK && sample projects but I haven't done the same for the depot_tools yet.

Versions matching

$ cat flutter/bin/internal/engine.version && cat depot_tools/.gclient
9b5f59ec3d54815931662a78a6ef34aa38bd5270
solutions = [
  {
    "managed": False,
    "name": "src/flutter",
    "url": "https://github.com/flutter/engine.git@9b5f59ec3d54815931662a78a6ef34aa38bd5270",
    "custom_deps": {},
    "deps_file": "DEPS",
    "safesync_url": "",
  },
]

[psstoyanov]

Update with RK3399 system - PinebookPro running ManjaroARM kernel 5.11.3 && mesa 20.3.4 using the DRM mode:

• Switching to tty3 and running the drm mode produces the expected app. The text is visible, the touchpad is functional 👍
• The output produces some errors and warnings but I don't see problem with the app itself

Detailed log with lldb

lldb ./flutter-drm-backend ./sample/build/linux/arm64/release/bundle
(lldb) target create "./flutter-drm-backend"
Current executable set to '/home/pak0st/flutter-embedded-linux/build/flutter-drm-backend' (aarch64).
(lldb) settings set -- target.run-args  "./sample/build/linux/arm64/release/bundle"
(lldb) run
Process 2714 launched: '/home/pak0st/flutter-embedded-linux/build/flutter-drm-backend' (aarch64)
[WARNING][linuxes_window_drm.cc(102)] FLUTTER_DRM_DEVICE is not set, use /dev/dri/card0
[WARNING][context_egl.h(95)] Failed to create EGL off-screen surface.(eglGetError: EGL_BAD_ALLOC)
[WARNING][linuxes_surface_gl_drm.h(50)] Off-Screen surface is invalid.
[ERROR][native_window_drm.cc(89)] TODO: implement here!!
[ERROR][flutter_linuxes_view.cc(60)] Failed to change surface size.
[ERROR:flutter/shell/platform/embedder/embedder_surface_gl.cc(102)] Could not create a resource context for async texture uploads. Expect degraded performance. Set a valid make_resource_current callback on FlutterOpenGLRendererConfig.
[ERROR:flutter/shell/platform/embedder/embedder_surface_gl.cc(102)] Could not create a resource context for async texture uploads. Expect degraded performance. Set a valid make_resource_current callback on FlutterOpenGLRendererConfig.
[ERROR][native_window_drm.cc(311)] Unsupported cursor: 

[psstoyanov]

Small update towards my experiments on x64 with my Ryzen/RDNA2 machine:

• Still experiencing the error with wrong Dart VM version when compiling the libraries (fresh flutter sdk/ depot_tools). What I find even more perplexing is that the exact same setup used on my aarch64 devices works.

• When using the debug library from Google's infrastructure, I get the following error when running the wayland client in Weston:

[ERROR:flutter/shell/common/shellcc(103)] Dart Error: Can't load Kernel binary: Invalid kernel binary format version.

The closest Flutter ticket to what I experience appears to be this one: flutter/flutter#64849

[LefixBlue]

Hi, I follow your work regarding flutter and embedded for a while already and I am very happy about it, because I share the same view of Sony regarding flutter and embedded linux! And it's amazing to see it running now on embedded devices..

Now lets come to my test:

• I have running a Yocto (master branch for all layers) core-image-base for raspberry-64. I have added all needed dependencies, as well as clang from meta-clang and can successfully build everything and use your flutter-client within weston aswell as the drm-backend directly from within the CLI. Great stuff!

• First I was thinking the flutter-client can be used without weston, directly from within CLI, but that was probably more related to my little understanding about it. For now I would say the DRM-Backend is the way to go if you only need a single application for your embedded device and then the wayland and weston stuff can be dropped completely. But of course that's project decision.

• However I got some compilation errors due to wrongly set includes when building directly on the Pi. I use clang12 built from meta-clang into the raspberrry image. Error was about unordered_map includes missing in at least one header file (key_event_plugin.h). But building the source cross from yocto didn't throw that error but for my understanding it has to be fixed.

• Furthermore I am still a bit unhappy about the fact that we still need GTK+3 to be able to build die Linux-Desktop-App before being able to use it with the embedder. Isn't it the case that we just need to app.so plus the assets from the desktop bundle? But for long term I will integrate everything into my yocto build, I am just waiting to cross compile feature will be enabled.

• Another issue I would like to address, which probably more flutter related -> Very HIGH CPU load for Linux Desktop either on x64 with a normal desktop build and as well as on arm64, and of course also with your embedder, 1 rasperry core is always running on 100% when flutter app in running with drm-backend. But that seems a general flutter thing, because I have an old release build of an x64 desktop app here which is not that cpu hungry, as when I rebuild it with the current master branch. I would be interested if i am the only one facing this cpu related problems or at least someone else could confirm that.

So far from my side. I am looking forward to the cross compile feature! If someone can give me a hint how to generate the app.so manually on an x64 (without the needs to wait the related PR to be merged) would also be cool.

[HidenoriMatsubayashi]

@LefixBlue

Thank you for your comments. Those are helpful.

Error was about unordered_map includes missing in at least one header file (key_event_plugin.h).

I fixed that (#22)

[HidenoriMatsubayashi]

@LefixBlue

In terms of cross-building, I'm going to send a PR to add cross-building support into the Flutter SDK. I'll do it in March.

If someone can give me a hint how to generate the app.so manually on an x64

Yes, see: https://github.com/flutter/flutter/wiki/Custom-Flutter-Engine-Embedding-in-AOT-Mode#building-the-aot-snapshot

[LefixBlue]

@HidenoriMatsubayashi
Thank you for the link regarding snapshots.
I will have a look into it.

[LefixBlue]

@HidenoriMatsubayashi

After reading the provided link I was still unsure where to get the correct gen_snapshot from. But now I just realized that building the engine for arm64 on x64 will produce a gen_snapshot in clang_x64/exe.unstripped folder with simarm64 target. So this one can be used on x64 to "cross-compile" the app.dill to app.so for arm64.

Thanks for your help!

[psstoyanov]

@LefixBlue check #21 for:

First I was thinking the flutter-client can be used without weston, directly from within CLI, but that was probably more related to my little understanding about it.

I agree that side-stepping the GTK app compile will be great once the embedder matures enough :)