Disable WebKitGTK DMA-BUF renderer on NVIDIA

[vltic]

What breaks

On a machine with an NVIDIA GPU, WebKitGTK apps do not start under Omarchy.

Apps using the system webkit2gtk-4.1 die at window creation:

Gdk-Message: Error 71 (Protocol error) dispatching to Wayland display.

Apps that bundle their own WebKit (Tauri apps, AppImages) abort outright:

Could not create GBM EGL display: EGL_SUCCESS. Aborting...

Different symptoms, one cause: WebKitGTK's DMA-BUF renderer does not work against NVIDIA's EGL driver on Wayland.

Minimal reproduction

No third-party app required — this uses only the system WebKitGTK:

# wk-test.py
import gi
gi.require_version('Gtk', '3.0')
gi.require_version('WebKit2', '4.1')
from gi.repository import Gtk, WebKit2, GLib

w = Gtk.Window(title="wk-egl-test")
w.set_default_size(320, 200)
v = WebKit2.WebView()
v.load_html("<h1>test</h1>", None)
w.add(v)
w.show_all()
GLib.timeout_add(3000, lambda: (print("SURVIVED"), Gtk.main_quit())[1])
Gtk.main()

python3 wk-test.py fails. WEBKIT_DISABLE_DMABUF_RENDERER=1 python3 wk-test.py prints SURVIVED.

The fault is NVIDIA's EGL driver

Three runs per condition:

Condition	Result
stock (NVIDIA EGL, DMA-BUF renderer on)	failed 3/3
WEBKIT_DISABLE_DMABUF_RENDERER=1	survived 3/3
__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json	survived 3/3

The third row is the control: same machine, same DMA-BUF renderer, Mesa's EGL instead of NVIDIA's, and it works. That rules out the renderer itself and points at the driver.

It is not caused by Omarchy's existing NVIDIA environment

Condition	Result
unset __GLX_VENDOR_LIBRARY_NAME	failed
unset NVD_BACKEND	failed
unset LIBVA_DRIVER_NAME	failed
unset all three	failed
unset all three, plus GDK_BACKEND	failed
GDK_BACKEND=x11	survived
GDK_BACKEND=wayland	failed

None of the variables this file already sets are implicated. The failure is Wayland-specific, and default/hypr/envs.lua sets GDK_BACKEND=wayland,x11,*, so Omarchy routes users onto the failing path by default. That is why it seems worth carrying the mitigation here rather than leaving every affected user to discover it.

Why it is scoped to the two driver branches

omarchy-hw-nvidia matches any NVIDIA display device, but the two branch detectors do not cover everything it matches: -gsp is device id >= 0x1e00 and -without-gsp is 0x1340 <= id < 0x1e00. Pre-Maxwell cards match the outer check and neither branch, so they currently get no NVIDIA environment at all, and they render through nouveau on Mesa — unaffected, per the control row above.

Setting the variable in the outer block would therefore have cost those machines the accelerated renderer for no benefit. It is set only inside the two branches, where Omarchy has already committed to NVIDIA's driver stack.

Tradeoff

The fallback renderer is slower than the DMA-BUF path, so this trades some WebKit compositing performance for these apps starting at all.

The case it over-applies to is a hybrid machine whose apps already render on the integrated GPU: WebKit would have been fine there, and this makes it slower. Narrowing further would need a reliable "is NVIDIA actually the rendering GPU" test, and I did not find one robust enough to propose. Flagging it in case you would rather scope it differently.

Verified on

• Omarchy 4.0.2-1, Hyprland 0.56.2-1
• webkit2gtk-4.1 2.52.6-1
• nvidia-open-dkms and nvidia-utils 610.57.04-1, kernel 7.1.9.arch1-2
• Ada-generation discrete GPU (GSP branch) alongside an AMD integrated GPU

Single machine. Not tested on NVIDIA-only systems, on the proprietary (non-open) driver, or on the -without-gsp branch, though the mechanism is the same EGL driver in all cases.

---

Filed by Claude Opus 5 via Claude Code.

🤖 Generated with Claude Code