Dinesh Jinjala
All posts

Fixing Chromium Scroll Flicker on Arch Linux + Omarchy (Hyprland)

14 March 2026 · Linux, Chromium, Hyprland, NVIDIA, Debugging

So I’ve been running Omarchy on Hyprland for a while now, and everything’s been solid. Until Chromium decided to lose its mind.

The Problem

Scrolling through x.com (the home timeline specifically), one pane just starts shaking. Not the whole screen — the rest of the monitor was completely fine. Just this one browser pane flickering like it was having a seizure every time I scrolled.

At first I thought it was an x.com thing. Tried other sites. Some were fine, some weren’t. The pattern was always the same though — scroll-triggered flicker in a single composited pane.

This drove me insane for like two hours.

My Setup

  • OS: Arch Linux (Omarchy)
  • WM: Hyprland
  • Browser: Chromium 145
  • GPU: Hybrid Intel + NVIDIA (Optimus)

That last one is the key. Hybrid GPU on Wayland is where all the fun bugs live.

Digging Into chrome://gpu

Opened up chrome://gpu and immediately saw the problem. The log section was just filled with errors:

eglCreateImage failed with 0x00003009
OzoneImageBacking::ProduceSkiaGanesh failed
SharedImageManager::ProduceSkia ... incompatible backing

These were repeating constantly. Basically Chromium was trying to import GPU buffers from one GPU path and the compositor was expecting another. Classic hybrid GPU nonsense on Wayland.

Hardware acceleration showed as “enabled” in the status section, which is the misleading part. It’s technically on, but the cross-GPU buffer handling is broken underneath.

What Didn’t Work

I tried a bunch of stuff before finding the actual fix.

Just launching with --ozone-platform=wayland — no change, error spam continued.

--use-gl=desktop — different errors, still flickered.

Setting LIBVA_DRIVER_NAME=iHD globally — partially helped but the EGL vendor was still wrong so buffers still failed.

Enabling WaylandLinuxDrmSyncobj via chrome://flags — honestly this one was weird. It worked at first. I got excited. Restarted Chromium normally the next day and the flicker was back. Turns out the flag was being applied but the environment variables from my terminal session weren’t carrying over when I launched from the app menu. Pain in the ass to debug.

--disable-gpu-compositing — this “fixed” it by just… turning off GPU compositing entirely. Everything was software rendered and looked terrible. Not a real solution.

The Actual Fix

Three pieces, and you need all of them.

1. Chromium Flags

Edit ~/.config/chromium-flags.conf:

--ozone-platform=wayland
--ozone-platform-hint=wayland
--enable-features=TouchpadOverscrollHistoryNavigation,WaylandLinuxDrmSyncobj
--load-extension=~/.local/share/omarchy/default/chromium/extensions/copy-url

The WaylandLinuxDrmSyncobj feature flag is the important one here. It fixes the DRM sync object handling between the compositor and the browser’s GPU process.

(If you use Brave, mirror the --enable-features line in ~/.config/brave-flags.conf too.)

2. Per-Browser Wrapper Script

This is the part I was missing for the longest time. Create ~/.local/bin/chromium:

#!/bin/bash
unset __GLX_VENDOR_LIBRARY_NAME
unset NVD_BACKEND
export LIBVA_DRIVER_NAME=iHD
export __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json

bin=/usr/lib/chromium/chromium
if [[ ! -x $bin ]]; then
  bin=/usr/bin/chromium
fi
exec "$bin" "$@"

Then:

chmod +x ~/.local/bin/chromium

What this does: forces Chromium’s GPU process to use Intel’s Mesa EGL path instead of NVIDIA’s. We unset the GLX vendor and NVD backend so they don’t interfere. The LIBVA_DRIVER_NAME=iHD points VAAPI at Intel, and the __EGL_VENDOR_LIBRARY_FILENAMES makes sure the EGL vendor file is Mesa’s, not NVIDIA’s.

3. Desktop Entry Override

This is why my fix kept “disappearing.” The wrapper only works if Chromium is actually launched through it. When you click the Chromium icon in your launcher, it uses the .desktop file, which points at the system binary directly.

Create ~/.local/share/applications/chromium.desktop:

[Desktop Entry]
Version=1.0
Name=Chromium
Exec=/home/YOUR_USER/.local/bin/chromium %U
Terminal=false
Type=Application
Icon=chromium
Categories=Network;WebBrowser;
Actions=new-window;new-private-window;

[Desktop Action new-window]
Name=New Window
Exec=/home/YOUR_USER/.local/bin/chromium

[Desktop Action new-private-window]
Name=New Incognito Window
Exec=/home/YOUR_USER/.local/bin/chromium --incognito

Replace YOUR_USER with your actual username obviously.

Then refresh the desktop database:

update-desktop-database ~/.local/share/applications

Restart Chromium completely (not just a new tab — kill the whole process tree and relaunch).

Verifying It Worked

After restarting:

  • Go back to the page that was flickering. Scroll around. Should be smooth now.
  • Open chrome://gpu again and check the log section. The eglCreateImage error spam should be gone or drastically reduced.

If you want to be thorough, you can verify the GPU process actually picked up the env vars:

gpu_pid=$(pgrep -f '/usr/lib/chromium/chromium --type=gpu-process' | head -1)
tr '\0' '\n' < /proc/$gpu_pid/environ | rg 'LIBVA_DRIVER_NAME|__EGL_VENDOR_LIBRARY_FILENAMES'

You should see:

LIBVA_DRIVER_NAME=iHD
__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json

What I Tested (Summary)

  • Baseline (no flags, no wrapper): massive eglCreateImage error spam, constant flicker on scroll
  • WaylandLinuxDrmSyncobj flag only: improved but inconsistent — regressed on relaunch from app menu
  • --use-gl=desktop: different errors, still broken
  • LIBVA_DRIVER_NAME=iHD alone: partial fix, EGL vendor still wrong
  • LIBVA_DRIVER_NAME=iHD + EGL vendor override (in terminal): worked! But only from terminal
  • Full fix (wrapper + desktop entry + syncobj flag): stable, survives reboot, works from launcher
  • --disable-gpu-compositing (software fallback): “works” but defeats the purpose — everything is software rendered

Lessons

Honestly the debugging was more annoying than the fix itself. A few things I’ll remember:

  • If only one app flickers, it’s that app’s GPU pipeline. Not your monitor, not your compositor.
  • If only one pane flickers during scroll, it’s a composited layer / buffer import issue.
  • A fix that works from the terminal can totally fail from the app launcher if your env vars aren’t in the right place. The wrapper + .desktop override pattern is the reliable way.
  • Don’t go straight to --disable-gpu-compositing. That’s giving up. Fix the actual GPU path instead.

Rollback

If something goes wrong, just remove the wrapper and desktop override:

rm ~/.local/bin/chromium
rm ~/.local/share/applications/chromium.desktop
update-desktop-database ~/.local/share/applications

And revert the --enable-features line in ~/.config/chromium-flags.conf. Restart Chromium and you’re back to stock.

Anyway, hope this saves someone else a couple hours. Hybrid GPU on Wayland is getting better but it’s still got these sharp edges. If you’re on a similar setup and hit this, the wrapper script approach is solid.