chromium 103 does not build for imx8qm

[ambrice]

Building chromium-ozone-wayland on i.MX8QM for wayland only, no x11 libs. Have the following patch to disable dri:

diff --git a/content/gpu/BUILD.gn b/content/gpu/BUILD.gn
index 1a6063b03..c766f5ee3 100644
--- a/content/gpu/BUILD.gn
+++ b/content/gpu/BUILD.gn
@@ -135,7 +135,7 @@ target(link_target_type, "gpu_sources") {
   }
 
   # Use DRI on desktop Linux builds.
-  if (current_cpu != "s390x" && current_cpu != "ppc64" && is_linux &&
+  if (current_cpu != "s390x" && current_cpu != "ppc64" && is_linux && ozone_platform_x11 &&
       !is_castos) {
     configs += [ "//build/config/linux/dri" ]
   }

Similar patch worked for 101, but in 103 I'm getting a compilation error:

| python3 "../../build/toolchain/gcc_link_wrapper.py" --output="./chrome" -- aarch64-poky-linux-clang++ -target aarch64-poky-linux  -mlittle-endian -Qunused-arguments -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Wdate-time --sysroot=/var/tmp/yocto/work/aarch64-mx8-poky-linux/chromium-ozone-wayland/103.0.5060.129-r0/recipe-sysroot -Wl,--version-script=../../build/linux/chrome.map -fuse-ld=lld -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,-mllvm,-instcombine-lower-dbg-declare=0 -flto=thin -Wl,--thinlto-jobs=20 -Wl,--thinlto-cache-dir=thinlto-cache -Wl,--thinlto-cache-policy=cache_size=10\%:cache_size_bytes=40g:cache_size_files=100000 -Wl,-mllvm,-import-instr-limit=5 -fwhole-program-vtables -Wl,--no-call-graph-profile-sort -Wl,-O2 -Wl,--gc-sections -rdynamic -Wl,-z,defs -Wl,--as-needed -pie -Wl,--disable-new-dtags -Wl,--lto-O2 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fmacro-prefix-map=/var/tmp/yocto/work/aarch64-mx8-poky-linux/chromium-ozone-wayland/103.0.5060.129-r0=/usr/src/debug/chromium-ozone-wayland/103.0.5060.129-r0                      -fdebug-prefix-map=/var/tmp/yocto/work/aarch64-mx8-poky-linux/chromium-ozone-wayland/103.0.5060.129-r0=/usr/src/debug/chromium-ozone-wayland/103.0.5060.129-r0                      -fdebug-prefix-map=/var/tmp/yocto/work/aarch64-mx8-poky-linux/chromium-ozone-wayland/103.0.5060.129-r0/recipe-sysroot=                      -fdebug-prefix-map=/var/tmp/yocto/work/aarch64-mx8-poky-linux/chromium-ozone-wayland/103.0.5060.129-r0/recipe-sysroot-native=  -Wl,-z,relro,-z,now  -stdlib=libc++ -o "./chrome" -Wl,--start-group @"./chrome.rsp"  -Wl,--end-group  -latomic -ldl -lpthread -lrt -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lsmime3 -lnss3 -lsoftokn3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -latk-1.0 -latk-bridge-2.0 -lgio-2.0 -ldbus-1 -lresolv -ljpeg -lexpat -luuid -ldrm -lxkbcommon -lm -lz -lwayland-client -lgbm -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lcairo -lasound -lwayland-egl -lpci -latspi -lFLAC -lxslt -lxml2
| aarch64-poky-linux-ld.lld: error: undefined symbol: gl::NativeViewGLSurfaceEGL::NativeViewGLSurfaceEGL(gl::GLDisplayEGL*, void*, std::__1::unique_ptr<gfx::VSyncProvider, std::__1::default_delete<gfx::VSyncProvider> >)

[maskimthedog]

I am seeing the same issue building chromium-ozone-wayland for wayland only for i.MX8MM after applying the same patch.

| aarch64-poky-linux-ld.lld: error: undefined symbol: gl::NativeViewGLSurfaceEGL::NativeViewGLSurfaceEGL(gl::GLDisplayEGL*, void*, std::__1::unique_ptr<gfx::VSyncProvider, std::__1::default_deletegfx::VSyncProvider >) | >>> referenced by gl_surface_wayland.cc:35 (./../../ui/ozone/platform/wayland/gpu/gl_surface_wayland.cc:35) | >>> thinlto-cache/Thin-7f2605.tmp.o:(ui::GLSurfaceWayland::GLSurfaceWayland(gl::GLDisplayEGL*, std::__1::unique_ptr<wl_egl_window, ui::EGLWindowDeleter>, ui::WaylandWindow*))

[ensc]

The immediate problem is that from

#elif defined(__GBM__)
typedef void               *EGLNativeWindowType;
...
#elif defined(USE_OZONE)
typedef intptr_t EGLNativeWindowType;

the first branch is used for some sources while the second one for other. This changes C++ function signatures.

[ensc]

setting

CXXFLAGS += "-D__GBM__"

workarounds it for me.

[5o5uk3]

Hello,

I had exactly the same issue (but with chromium 105 build) and I have chosen the opposite approach. From my point of view gbm.pc file should not add -D__GBM__ flag as it is already set through gbm.h when it is included. That's why I have patched imx-gpu-viv_6.4.3.p2.0-aarch64 recipe to remove this flag and the chromium compilation is OK. FYI, the patch applied below:

Index: imx-gpu-viv-6.4.3.p2.0-aarch64/gpu-core/usr/lib/pkgconfig/gbm.pc
===================================================================
--- imx-gpu-viv-6.4.3.p2.0-aarch64.orig/gpu-core/usr/lib/pkgconfig/gbm.pc
+++ imx-gpu-viv-6.4.3.p2.0-aarch64/gpu-core/usr/lib/pkgconfig/gbm.pc
@@ -8,4 +8,4 @@ Description: vivante gbm library
 Version: 17.2
 Libs: -L${libdir} -lgbm
 Libs.private: -ldl
-Cflags: -I${includedir} -DLINUX -D__GBM__
+Cflags: -I${includedir} -DLINUX

[Villemoes]

Building for imx8mp, having the same issue. Any consensus on whether it needs fixing in chromium or imx-gpu-viv?

[5o5uk3]

@Villemoes What I can assert is that chromium does not seem to use GPU acceleration with my method. I have to check if it behaves better with open source drivers.

[amcelroy]

setting

CXXFLAGS += "-D__GBM__"

workarounds it for me.

Howdy, I'm trying to get Chromium compiled for Dunfell Yocto for an iMX8X and am hitting this error. Which file did you add the CXXFLAGS += "-D__GBM__" to?

Edit: Might have figured it out; I put it at the bottom of /layers/meta-browser/meta-chromium/recipes-browser/chromium/chromium-ozone-wayland_110.0.5481.77.bb. Everything compiled correctly, will have to check about GPU accel.

[ambrice]

We have been stuck on chromium 92 on i.MX8QM for a while but I copied this recipe from NXP's meta-imx layer:

https://github.com/nxp-imx/meta-imx/tree/langdale-6.1.1-1.0.0/meta-sdk/dynamic-layers/chromium-browser-layer/recipes-browser/chromium/

Seems to work, with GPU acceleration, gets us to chromium 101 at least. I'm using with commit 6079a8b67da524d6cb19c163e689b21e0d7575b1 of meta-browser for chromiums 101 recipe.

[maskimthedog]

We have been stuck on chromium 92 on i.MX8QM for a while but I copied this recipe from NXP's meta-imx layer:

https://github.com/nxp-imx/meta-imx/tree/langdale-6.1.1-1.0.0/meta-sdk/dynamic-layers/chromium-browser-layer/recipes-browser/chromium/

Seems to work, with GPU acceleration, gets us to chromium 101 at least. I'm using with commit 6079a8b of meta-browser for chromiums 101 recipe.

What about hardware video decode?

[ambrice]

I haven't tried hardware video decode but a commit says it was added:

commit fe0d3587d905a8fa32a9830d177f97c90352fdc5 Author: Hou Qi [email protected] Date: Thu Sep 15 22:28:13 2022 +0800

chromium-ozone-wayland: Add V4L2VDA support on Linux [YOCIMX-6545]

    - support on i.MX 8 series platform.
    - 8MM/8MP/8MQ support h264/hevc/vp8/vp9 hardware decoding.
    - 8QM/8QXP support h264/hevc/vp8 hardware decoding.
    - support seek, playrate change and resolution change.
    - support video acceleration for online media platform such as Youtube, bilibili.

[maskimthedog]

I haven't tried hardware video decode but a commit says it was added:

commit fe0d3587d905a8fa32a9830d177f97c90352fdc5 Author: Hou Qi [email protected] Date: Thu Sep 15 22:28:13 2022 +0800

chromium-ozone-wayland: Add V4L2VDA support on Linux [YOCIMX-6545]

    - support on i.MX 8 series platform.
    - 8MM/8MP/8MQ support h264/hevc/vp8/vp9 hardware decoding.
    - 8QM/8QXP support h264/hevc/vp8 hardware decoding.
    - support seek, playrate change and resolution change.
    - support video acceleration for online media platform such as Youtube, bilibili.

Wow, that's very timely. I will check it out. Thank you.

[maskimthedog]

fe0d3587d905a8fa32a9830d177f97c90352fdc5

I haven't tried hardware video decode but a commit says it was added:

commit fe0d3587d905a8fa32a9830d177f97c90352fdc5 Author: Hou Qi [email protected] Date: Thu Sep 15 22:28:13 2022 +0800

chromium-ozone-wayland: Add V4L2VDA support on Linux [YOCIMX-6545]

    - support on i.MX 8 series platform.
    - 8MM/8MP/8MQ support h264/hevc/vp8/vp9 hardware decoding.
    - 8QM/8QXP support h264/hevc/vp8 hardware decoding.
    - support seek, playrate change and resolution change.
    - support video acceleration for online media platform such as Youtube, bilibili.

You tested on Langdale, Kirkstone or Dunfell?

[maskimthedog]

One of our engineers was able to get video decode in Chromium on Langdale. Video rendering looks good and CPU usage is very minimal.

[otavio]

Is the patchset public?

[ambrice]

Yes, available at https://github.com/nxp-imx/meta-imx/tree/langdale-6.1.1-1.0.0/meta-sdk/dynamic-layers/chromium-browser-layer/recipes-browser/chromium/

[russdill]

I've found this to be a somewhat smaller hammer

diff --git a/ui/gl/BUILD.gn b/ui/gl/BUILD.gn
index 761888bf4a540..0d31ab3b34f35 100644
--- a/ui/gl/BUILD.gn
+++ b/ui/gl/BUILD.gn
@@ -260,6 +260,13 @@ component("gl") {
       if (angle_shared_libvulkan && !is_chromeos) {
         data_deps += [ "//third_party/vulkan-deps/vulkan-loader/src:libvulkan" ]
       }
+      defines += [ "WAYLAND_GBM" ]
+
+      deps += [
+        "//third_party/minigbm",
+        "//ui/gfx:memory_buffer",
+        "//ui/gfx/linux:gbm",
+      ]
     }
   }

[russdill]

One of the changes chromium 114 brought in was 20f14755 "ui: gbm_wrapper: Ensure to create BOs with import-compatible modifier". This change doesn't play well with the imx gbm library. One issue is that the file descriptors to things within the gbm_bo are kept open across a call to gbm_bo_destroy, which causes errors on close. Another issue is that the library doesn't seem to react well with this attempt to use different modifiers within a loop. 9ccd092ec "[m114] Close FDs after use in gbm_wrapper::Device:CereateBufferWithModifiers()" sits on top of this commit, so reverting it is also necessary.

[russdill]

The imx gbm library hardcodes dri device nodes but still implements the calls to request them. This patch allows chrome to ignore the ones returned in favor of env vars.

From a51a2a3a567cba945cfa89368924bbfe3f0657ad Mon Sep 17 00:00:00 2001
From: Russ Dill <[email protected]>
Date: Mon, 17 Jul 2023 04:42:10 -0700
Subject: [PATCH 3/7] drm: Allow render node and dri file to be specified

---
 ui/ozone/platform/drm/gpu/gbm_surface_factory.cc             | 5 +++++
 ui/ozone/platform/wayland/gpu/drm_render_node_path_finder.cc | 4 ++++
 2 files changed, 9 insertions(+)

diff --git a/ui/ozone/platform/drm/gpu/gbm_surface_factory.cc b/ui/ozone/platform/drm/gpu/gbm_surface_factory.cc
index b77c1aa2f7bb4..d9fa29c8c994d 100644
--- a/ui/ozone/platform/drm/gpu/gbm_surface_factory.cc
+++ b/ui/ozone/platform/drm/gpu/gbm_surface_factory.cc
@@ -9,6 +9,7 @@
 
 #include <memory>
 #include <utility>
+#include <string.h>
 
 #include "base/containers/contains.h"
 #include "base/files/file_path.h"
@@ -207,6 +208,10 @@ std::vector<gfx::BufferFormat> EnumerateSupportedBufferFormatsForTexturing() {
     base::FilePath dev_path(FILE_PATH_LITERAL(
         base::StringPrintf(kRenderNodeFilePattern, i).c_str()));
 
+    const char *str = getenv("DRM_RENDER_NODE_FILE");
+    if (str && strcmp(str, base::StringPrintf(kRenderNodeFilePattern, i).c_str()))
+        continue;
+
     ScopedAllowBlockingForGbmSurface scoped_allow_blocking;
     base::File dev_path_file(dev_path,
                              base::File::FLAG_OPEN | base::File::FLAG_READ);
diff --git a/ui/ozone/platform/wayland/gpu/drm_render_node_path_finder.cc b/ui/ozone/platform/wayland/gpu/drm_render_node_path_finder.cc
index cdce6ae0d34db..c9aa6461829c8 100644
--- a/ui/ozone/platform/wayland/gpu/drm_render_node_path_finder.cc
+++ b/ui/ozone/platform/wayland/gpu/drm_render_node_path_finder.cc
@@ -54,6 +54,10 @@ void DrmRenderNodePathFinder::FindDrmRenderNodePath() {
     if (len >= 4 && memcmp(device_link + len - 4, "vgem", 4) == 0)
       continue;
 
+    const char *str = getenv("DRM_RENDER_NODE_FILE");
+    if (str && strcmp(str, base::StringPrintf(kDriRenderNodeTemplate, i).c_str()))
+        continue;
+
     std::string dri_render_node(base::StringPrintf(kDriRenderNodeTemplate, i));
     base::ScopedFD drm_fd(open(dri_render_node.c_str(), O_RDWR));
     if (drm_fd.get() < 0)
-- 
2.34.1

[asdasdomar]

One of the changes chromium 114 brought in was 20f14755 "ui: gbm_wrapper: Ensure to create BOs with import-compatible modifier". This change doesn't play well with the imx gbm library. One issue is that the file descriptors to things within the gbm_bo are kept open across a call to gbm_bo_destroy, which causes errors on close. Another issue is that the library doesn't seem to react well with this attempt to use different modifiers within a loop. 9ccd092ec "[m114] Close FDs after use in gbm_wrapper::Device:CereateBufferWithModifiers()" sits on top of this commit, so reverting it is also necessary.

Yes, reverting those commits worked for me as well. Thanks

[escherstair]

Hello to everybody, this issue is more than one year old (at the moment). It's for chromium v103, but then (some months after) v105 and v114 are mentioned. My question is: can the latest release available at the moment (I imagine v118 or v119) be built without issues for imx8qm/imx8mp? Are patches required for a successful build?

[VaginAY]

Confirm for 123 version. After make all patches from meta-browser applicable (or remove such backport).

Pathces from meta-imx doesn't help.

[georgekelly1097]

It seems NXP attempted to patch this twice.

First in meta-imx commit https://github.com/nxp-imx/meta-imx/commit/45ae537ebe435c25c53ecb982840deeae2a73fca with the comment " Disable VPU temporarily until the patches are rebased based on newer version of chromium". Then they reverted that in commit 5401bc9.

Next, they renamed the top level folder "meta-sdk" to "meta-sdk-imx", so the commit history is hard to follow. Now NXP's chromium patches are here: https://github.com/nxp-imx/meta-imx/tree/nanbield-6.6.3-1.0.0/meta-imx-sdk/dynamic-layers/chromium-browser-layer/recipes-browser/chromium/chromium-ozone-wayland. It appears that these 3 patches are the relevant ones: 0004-Fix-chromium-build-failure.patch
0005-Revert-ui-gbm_wrapper-Ensure-to-create-BOs-with-impo.patch
0006-Fixed-chromium-crash-after-upgrading.patch \

I've got a build chugging now to see if they resolve this issue