Chromium does not run after latest unstable update

So, for the flatpak version of chromium, our good old “chromium-flags.conf” file can be copied from its original place (/home/ ***** /config) and pasted into (/home/ ***** /.var/app/org.chromium.Chromium/config/). Here is the content of mine:

--use-angle=gles
--ignore-gpu-blocklist
--enable-zero-copy
--enable-features=MiddleClickAutoscroll
--ozone-platform-hint=auto
--js-flags="--no-decommit-pooled-pages"
--disable-gpu-vsync
--enable-widevine

To enable the “sync” function, we need to add two environment variables (they are universal, no need to change). It is very simple, just open a terminal and enter the following line:

flatpak override --user --env=GOOGLE_DEFAULT_CLIENT_ID=77185425430.apps.googleusercontent.com --env=GOOGLE_DEFAULT_CLIENT_SECRET=OTJgUOQcT7lO7GsGZq2G4IlT org.chromium.Chromium

Once you enter this, it is saved and chromium always opens with these environment variables so nothing extra is required.

To have widevine, i am assuming that you already have the widevine package installed from git, you need to find the “widevineCdm/chromium” folder. In my setup, it is in “/opt/WidevineCdm/chromium/”. Now we will copy and paste “the contents” of this folder, into right here:

/home/ ***** /.var/app/org.chromium.Chromium/config/chromium/WidevineCdm/4.10.2710.0/

Pay attention that the folder name is the “version number” of the current widevine setup (you need to create it), and in our case, the version number is probably the same, as we all are using the same widevine from the same github repository.

Also i wasn’t sure if it was necessary or not but i added the “--enable-widevine” line to the chromium-flags.conf file, just to make sure.

That is pretty much it.

PS: ***** is your username.

PS-2: A couple open/close chromium cycles may be necessary for the widevine to fully work.

i have try

flatpak override --user --filesystem=/opt/WidevineCdm/chromium/ org.chromium.Chromium

But no success with that.
It need a copy in a specific directory

cp -r /opt/WidevineCdm/chromium/* ~/.var/app/org.chromium.Chromium/config/chromium/WidevineCdm/4.10.2710.0

Other interesting command

flatpak override --show --user org.chromium.Chromium
flatpak override --user --reset org.chromium.Chromium

to show or reset

But

--js-flags="--no-decommit-pooled-pages"
--enable-widevine

are not required.

I think you did things a little bit differently than i did but if it works for you, it should be good.

--js-flags="--no-decommit-pooled-pages"

This was necessary for the chromium package from our manjaro repo. If it is not necessary for the flatpak version, maybe i shall remove it.

Another system update, another broken Chromium :slight_smile: It is almost expected as default at this point.

This time, the issue is KDE Plasma’s stupid “kwallet” subsystem. I have never used, nor have i any future plans to use this s.h.i.t so i have no idea why they are shoving it down our throats. It is a dependency and you can not remove it. Embedded into the system. I would try to force-remove it but then i am scared that the system will not boot anymore. The only thing i hate about KDE Plasma is this “kwallet” thing.

I love Kwallet. I’ve used it since 2000, when I first installed Mandrake Linux with KDE.

In fact I like Kwallet so much that I installed it on my Ubuntu and Linux Mint Systems, and anything else I used between Mandrake and Manjaro.

Kwallet is where I store all my passwords, and any other data that needs to be remembered.

I am sorry but, without any cloud storage solution (which is what kwallet lacks), storing sensitive data like passwords on my local machine would be a recipe for disaster for me. Without a reliable redundancy, that would mean losing all my passwords in the case of a drive failure.

What i use instead is the google password manager. The moment i create a new username/password, it automatically stores it in my account. No muss no fuss.

No need to appologise, we all have our preferences.

What’s weird is that chromium compiles perfectly but arch doesn’t update.
chromium-136.0.7103.92-1-aarch64.pkg.tar.zst

1 Like

Hi @tartanpion, Thanks for shairing the new Chromium_v136. Just checking whether v4l2request option has been enabled in this Chromium_136 build?

No.
https://github.com/saiarcot895/chromium-ubuntu-build/issues/65

use_v4l2_codec=true
use_vaapi=false

It looks like we’ll have to put this in build and maybe some other argument to launch chromium. And look at chrome://media-internals/ and chrome://gpu

Arch arm doesn’t include it and it’s not even worth making a request on the forum or even on the github. Whoever manages it won’t be taken into account…

chromium rule from rpios

# set the appropriate cpu architecture
DEB_HOST_ARCH_value := $(shell dpkg-architecture -qDEB_HOST_ARCH)
DEB_HOST_ARCH ?= $(DEB_HOST_ARCH_value)
ifeq (i386,$(DEB_HOST_ARCH))
defines+=host_cpu=\"x86\" use_vaapi=true
endif
ifeq (amd64,$(DEB_HOST_ARCH))
defines+=host_cpu=\"x64\" use_vaapi=true
endif
ifeq (arm64,$(DEB_HOST_ARCH))
defines+=host_cpu=\"arm64\" use_v4l2_codec=true use_vaapi=false
endif
ifeq (armhf,$(DEB_HOST_ARCH))
defines+=host_cpu=\"arm\" use_v4l2_codec=true use_vaapi=false arm_use_neon=true
endif

And I don’t know how the ffmpeg version is managed.

Firefox uses the local version.But I think it only supports v4l2 stateful (ok for rpi but not for rockchip).

Installed chromium_v136 on Opi5-Plus. Unfortunately v4l2request not enabled as such no vpu hw acceleration with chromium_v136 using mainline kernel linux-6.14.

Was informed the current Debian Chromium builds have v4l2request enabled, amazingfate ppa chromium build does support v4l2request. Tested it before on amazingfate’s Debian-Trixie-hybrid-iso.

Unfortunately not on rockchip soc.

In fact it’s seems not to be a question of stateful /stateless v4l2 api (more a ffmpeg problem) but rockchip devices are using v4l2-request rather than v4l2-m2m for decoders. For pi6 if they enable other video format acceleration it’s just a matter to set media.ffvpx.enabled to false use system ffmpeg for vp8/vp9/av1 decode in firefox. And to compile chromium with use_v4l2_codec=true use_vaapi=false.
For rockchip ?

Don’t really know unfortunately. Use amazingfate’s Debian Chromium_v135 build from Packages in “Chromium from debian” : Chromium from debian : JianFeng Liu

Based info from amazingfate, he had to revert on patch on the upstream Chromium to ensure Chromium to be stable on rk3588 when running with “–oznone-platform=wayland” needed for vpu hardware acceleration.

Edit: Without reverting the patch the upstream Chromium will randomly crash when run with the option “–ozone-platform=wayland”.

How so?
It fails for me an a x13s because of undefined symbols like __rustc::__rust_alloc

On my opi5+ it’s even worse, it can’t even build eu-strip because of a bunch of

<command-line>: error: missing terminating " character [-Werror]

It was all about testing. We still don’t know why it’s blocking the version. And it allowed me to see that it doesn’t even activate hardware video decoding for arm. I don’t have a big PC to do this with cross compilation and as I don’t use chromium I’m not going to have fun doing this often. I’m on unstable and I’ve started cloning arch repositories.

I managed to compile chromium 137. it took about 14 hours on a x13s.
I decided to enable v4l2 and disable vaapi (the code in chromium conflicts, only one can be enabled)
run it with

--enable-features=AcceleratedVideoDecoder,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL
1 Like

what went wrong in the past ?

I am still on flatpak chromium. It works fine. Performance is on par with what i could get on RPIOS so i am not really complaining. I start with the following flags (i also have some flags enabled within chromium://flags):

--use-angle=gles
--ignore-gpu-blocklist
--enable-zero-copy
--enable-features=MiddleClickAutoscroll
--ozone-platform-hint=auto
--disable-gpu-vsync
--enable-widevine

chrome://gpu:

Graphics Feature Status
=======================
*   Canvas: Hardware accelerated
*   Direct Rendering Display Compositor: Disabled
*   Compositing: Hardware accelerated
*   Multiple Raster Threads: Enabled
*   OpenGL: Enabled
*   Rasterization: Hardware accelerated on all pages
*   Raw Draw: Disabled
*   Skia Graphite: Disabled
*   Video Decode: Hardware accelerated
*   Video Encode: Software only. Hardware acceleration disabled
*   Vulkan: Disabled
*   WebGL: Hardware accelerated
*   WebGL2: Hardware accelerated
*   WebGPU: Disabled
*   WebNN: Disabled

Hmm. I think “ARM Team” tends to suggest otherwise. :slight_smile:

Thanks. Great.

Chromium_v137 V4l2request does indeed works with this “–ozone-platform=wayland” on Orange Pi 5 Plus with kernel-6.15. But unfortunately it will randomly crash on RK3588 device unless the Chromium build with this patch reverted. This is according to amazingfate with build/maintain the chromium package for Armbian

amazingfate — 7/17/24, 11:47 PM
I think I have found the commit causing chromium crash: https://github.com/chromium/chromium/commit/67d69c1b628b54c1442d8e494852d6403a21446a
After applying this commit to chromium v117 chromium would crash. I'm building chromium v126 with this commit reverted and see if crashing would dispear.
GitHub
ozone/wayland: Use implicit sync interop on kernel >= 6.0 if explic...
… sync protocol is unavailable

This change allows Chromium to use the implicit sync interop
functionality present in Linux 6.0 and later to synchronize with Wayland
compositors lacking support for...


amazingfate — 7/18/24, 9:42 AM
After reverting that commit chromium v126 doesn't crash anymore. I'm going to update chromium in my ppa with this commit reverted.

If you build Chromium again would it be possible to Revert this commit:

This will make Chromium with v4l2request available and stable on RK3588 devices. As far as I know it will not cause issue on other devices, tested it on GT King Pro.

image