flutter-embedded-linux
flutter-embedded-linux copied to clipboard
sony
Test on arm devices
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)
- [x] Wayland backend
- [x] DRM backend (https://github.com/sony/flutter-embedded-linux/issues/1)
-
Raspberry Pi4 (OS: Ubuntu 20) https://github.com/sony/flutter-embedded-linux/issues/9
- [x] Wayland backend
- [x] DRM backend
-
i.MX 8M Mini EVK (OS: Zeus, imx-5.4.70-2.3.1.xml)
- [x] Wayland backend ~~DRM backend~~ NXP doesn't support EGL for GBM.
-
RB5 (OS: Based Ubuntu 18.04)
- [x] DRM-GBM backend ~~Wayland backend~~ Weston version is 3.0 and it doesn't support xdg-shell
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
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.
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 :thinking: 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": "",
},
]
Update with RK3399 system - PinebookPro running ManjaroARM kernel 5.11.3 && mesa 20.3.4 using the DRM mode:
- Switching to
tty3and running the drm mode produces the expected app. The text is visible, the touchpad is functional :+1: - 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:
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: https://github.com/flutter/flutter/issues/64849
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.
@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 (https://github.com/sony/flutter-embedded-linux/pull/22)
@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
@HidenoriMatsubayashi Thank you for the link regarding snapshots. I will have a look into it.
@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!
@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 :)
Had some fun doing something unconventional tonight by compiling the embedder on MSM8916 device (Wileyfox Swift) with postmarketOS. It resulted in the following errors:
pmOS linker errors
➜ build git:(master) make
[ 3%] Linking CXX executable flutter-drm-backend
/usr/bin/ld: warning: libdl.so.2, needed by /usr/lib/libflutter_engine.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libpthread.so.0, needed by /usr/lib/libflutter_engine.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libm.so.6, needed by /usr/lib/libflutter_engine.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libc.so.6, needed by /usr/lib/libflutter_engine.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: ld-linux-aarch64.so.1, needed by /usr/lib/libflutter_engine.so, not found (try using -rpath or -rpath-link)
The errors have less to do with the embedder itself and more with Flutter/ Alpine linux.
There are several issues with the method I've use to conduct the attempt on this device tonight:
- postmarketOS is not meant to use dev libraries on the end user side
- The attempt was not conducted through pmbootstrap's chroot environment to compile the embedder PostmarketOS is great and has very close ties to Alpine linux - a great small distribution, perfect for embedded or specialized uses.
I will need to prepare a proper setup and try again but thought it would be interesting to share nonetheless.
Some new input from my side as well:
Building the "flutter-weston-dekstop-shell" not succeed in my environment. It already failed on my first attempt directly on the raspberry pi some days ago, but now I retried building it cross with yocto and getting the same result.
-
in main.cc: config.parser.h not found (i guess because my .pc file for libweston points to /usr/inlclude as include dir but the relevant headers are in /usr/include/libweston-9/libweston)
-
also in main.cc: 3rd argument of 'weston_config_section_get_bool' shoud be a 'bool-' instead of an 'int-'pointer
Thank you for your report! Actually, Weston is not backward compatible and we are looking for ways to support multiple versions. See also: https://github.com/sony/flutter-embedded-linux/issues/3
I've tried on i.MX 8M Mini EVK (OS: Zeus, imx-5.4.70-2.3.1.xml), but the embedder with DRM backend didn't work. Wayland backend is no problem.
root@imx8mmevk:~# FLUTTER_DRM_DEVICE=/dev/dri/card1 ./flutter-drm-backend ./bundle/
[ 1] ioctl(DRM_IOCTL_GEM_CLOSE) failed
[ERROR][native_window_drm.cc(42)] Failed to create the compositor surface.
[ERROR][linuxes_window_drm.cc(110)] Failed to create the native window
Wohoo! After some extensive cleanup on my host machine, I've found the offending piece causing me problems with the depot_tools. As it turns out, I've had a number of remnants of an AUR package - flutter-git that collided with my main Flutter install and was using different version. Whatever unintended referencing was happening there is no more.
So, I can finally confirm - the embedder does work with AMD RX6800 with the open source drivers using both the DRM and wayland clients. Mesa version installed on the x64 system - 20.3.4.
Note: Unlike with the arm devices I have, for the DRM session there was one card to be targeted - /dev/dri/card0
@HidenoriMatsubayashi
I also had a try on the actual iMX8M-MiniEVK BSP Release (OS: Gatesgarth 5.10.9) with the drm-backend. And unfortunately I got the same result as you mentioned here a while ago (ioctl failed). Is there already an explanation why this error happens? Or is the drm-backend not meant to run on the iMX8M-Platform at all?
We want to support the i.MX8M platform, so we need to investigate this issue. I think i.MX8M supports DRM and actually, Weston which uses the DRM backend works on i.MX8M mini. I'll investigate this week. Please tell me more if you have any information.
I am unfortunately not that deep into all these graphical backend stuff..
The only thing I observed today is that I ran into the same build-error like someone reported in #30 while building the drm-backend cross with yocto. You mentioned in #30 that the WL_EGL_PLATFORM define would be missing, but that didn't worked for me because in the drm-backend case we dealing with gbm. To get around the build-errors I finally (after try many different other things) tried to cast the relevant parameter in the calls eglCreateWindowSurface and eglGetDisplay to EGLNativeWindowType. It did build through then, but the result at runtime is that ioctl error.
No idea if that helps.
To get around the build-errors I finally (after try many different other things) tried to cast the relevant parameter in the calls eglCreateWindowSurface and eglGetDisplay to EGLNativeWindowType
If it's a bug, I'd like to fix it. Now, we are preparing yocto recipe examples.
~~In terms of i.mx8m, it looks like it doesn't support GBM_BO_FORMAT_ARGB8888. Probably I need to fix the code.~~
@HidenoriMatsubayashi
Please note the build-errors I mentioned in my last comment here in this thread regarding cross build drm-gbm-backend with yocto when not hard casting the problematic parameters to EGLNativeWindowType for iMX8M-Mini-EVK.
I use the actual Yocto iMX8M-MiniEVK BSP Release (OS: Gatesgarth 5.10.9) (Distro: fsl-imx-wayland):
| src/flutter/shell/platform/linux_embedded/window/native_window_drm_gbm.cc:43:13: error: incompatible pointer types assigning to 'EGLNativeWindowType' (aka 'wl_egl_window *') from 'struct gbm_surface *' | window_ = gbm_surface_create(gbm_device_, drm_mode_info_.hdisplay, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | src/flutter/shell/platform/linux_embedded/window/native_window_drm_gbm.cc:72:32: error: static_cast from 'EGLNativeWindowType' (aka 'wl_egl_window *') to 'gbm_surface *', which are not related by inheritance, is not allowed | gbm_surface_release_buffer(static_cast<gbm_surface*>(window_), | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | recipe-sysroot/usr/include/gbm.h:47:8: note: 'gbm_surface' is incomplete | struct gbm_surface; | ^ | recipe-sysroot/usr/include/EGL/eglplatform.h:96:16: note: 'wl_egl_window' is incomplete | typedef struct wl_egl_window *EGLNativeWindowType; | ^ | src/flutter/shell/platform/linux_embedded/window/native_window_drm_gbm.cc:74:25: error: static_cast from 'EGLNativeWindowType' (aka 'wl_egl_window *') to 'gbm_surface *', which are not related by inheritance, is not allowed | gbm_surface_destroy(static_cast<gbm_surface*>(window_)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | recipe-sysroot/usr/include/gbm.h:47:8: note: 'gbm_surface' is incomplete | struct gbm_surface; | ^ | recipe-sysroot/usr/include/EGL/eglplatform.h:96:16: note: 'wl_egl_window' is incomplete | typedef struct wl_egl_window *EGLNativeWindowType; | ^ | src/flutter/shell/platform/linux_embedded/window/native_window_drm_gbm.cc:140:44: error: static_cast from 'EGLNativeWindowType' (aka 'wl_egl_window *') to 'gbm_surface *', which are not related by inheritance, is not allowed | auto* bo = gbm_surface_lock_front_buffer(static_cast<gbm_surface*>(window_)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | recipe-sysroot/usr/include/gbm.h:47:8: note: 'gbm_surface' is incomplete | struct gbm_surface; | ^ | recipe-sysroot/usr/include/EGL/eglplatform.h:96:16: note: 'wl_egl_window' is incomplete | typedef struct wl_egl_window *EGLNativeWindowType; | ^ | src/flutter/shell/platform/linux_embedded/window/native_window_drm_gbm.cc:159:32: error: static_cast from 'EGLNativeWindowType' (aka 'wl_egl_window *') to 'gbm_surface *', which are not related by inheritance, is not allowed | gbm_surface_release_buffer(static_cast<gbm_surface*>(window_), | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | recipe-sysroot/usr/include/gbm.h:47:8: note: 'gbm_surface' is incomplete | struct gbm_surface; | ^ | recipe-sysroot/usr/include/EGL/eglplatform.h:96:16: note: 'wl_egl_window' is incomplete | typedef struct wl_egl_window *EGLNativeWindowType; | ^ | In file included from src/flutter/shell/platform/linux_embedded/window/native_window_drm_gbm.cc:5: | In file included from src/flutter/shell/platform/linux_embedded/window/native_window_drm_gbm.h:14: | In file included from src/flutter/shell/platform/linux_embedded/window/native_window_drm.h:12: | In file included from src/flutter/shell/platform/linux_embedded/surface/linuxes_surface_gl.h:8: | In file included from recipe-sysroot/usr/lib//aarch64-poky-linux/10.2.0/../../../include/c++/10.2.0/memory:83: | recipe-sysroot/usr/lib//aarch64-poky-linux/10.2.0/../../../include/c++/10.2.0/bits/unique_ptr.h:962:34: error: no matching constructor for initialization of 'flutter::EnvironmentEgl' | { return unique_ptr<_Tp>(new _Tp(std::forward<_Args>(__args)...)); } | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~ | src/flutter/shell/platform/linux_embedded/window/native_window_drm_gbm.cc:136:12: note: in instantiation of function template specialization 'std::make_unique<flutter::EnvironmentEgl, gbm_device *&>' requested here | std::make_unique<EnvironmentEgl>(gbm_device_))); | ^ | src/flutter/shell/platform/linux_embedded/surface/environment_egl.h:15:7: note: candidate constructor (the implicit copy constructor) not viable: cannot convert argument of incomplete type 'gbm_device *' to 'const flutter::EnvironmentEgl' for 1st argument | class EnvironmentEgl { | ^ | src/flutter/shell/platform/linux_embedded/surface/environment_egl.h:17:3: note: candidate constructor not viable: cannot convert argument of incomplete type 'gbm_device *' to 'EGLNativeDisplayType' (aka 'wl_display *') for 1st argument | EnvironmentEgl(EGLNativeDisplayType platform_display) | ^ | src/flutter/shell/platform/linux_embedded/surface/environment_egl.h:29:3: note: candidate constructor not viable: requires 0 arguments, but 1 was provided | EnvironmentEgl() : display_(EGL_NO_DISPLAY), valid_(false) {} | ^ | 6 errors generated.
@LefixBlue
I'll try to cross-build using the SDK (toolchain) which is generated by Yocto for iMX8M-MiniEVK BSP Release.
@LefixBlue Could you inform me of the manifest version you are using? imx-5.10.9-1.0.0.xml?
@HidenoriMatsubayashi
I am using imx-5.10.9-1.0.0.xml
They recently "upgraded" the BSP, see:
https://www.nxp.com/docs/en/user-guide/IMX_YOCTO_PROJECT_USERS_GUIDE.pdf
But I have to say that i used my own yocto recipe to build the drm-backend as I already started using your project before you integrated the yocto-recipes into the repository. So it could be a source of failure from my side. Even the recipes look more or less the same. At least I have cross checked the DEPENDS variable today.
@HidenoriMatsubayashi
Should the eglstream-backend also run on the i.MX8M-Mini-EVK?
Because I can build that backend successfully with the imx-5.10.9-1.0.0.xml BSP
But it fails with a segmentation fault at runtime:
$>FLUTTER_DRM_DEVICE=/dev/dri/card1 flutter-drm-eglstream-backend bundle
[ERROR][environment_egl_drm_eglstream.cc(15)] Failed to set extension function pointers
[ERROR][context_egl.cc(31)] Failed to choose EGL surface config: eglGetError: EGL_BAD_DISPLAY
[ERROR][context_egl_drm_eglstream.cc(20)] Failed to set extension function pointers