Summary
linuxdeploy-plugin-gtk.sh unconditionally sets export GDK_BACKEND=x11, citing
"Crash with Wayland backend on Wayland".
The linked justification (tauri-apps/tauri#8541) is actually about something narrower
than a Wayland crash, and forcing X11 for every app built with this plugin causes a
real regression on modern NVIDIA + Wayland systems: WebKitGTK falls back to
unaccelerated software rendering, and the app's WebProcess sits at sustained high CPU
for no reason.
What the cited issue (tauri#8541) actually says
tauri-apps/tauri#8541 is titled
"Run AppImage: GLib-GIO-ERROR Settings schema error". The actual bug: an AppImage
built inside an ubuntu:20.04 container crashed with
GLib-GIO-ERROR **: Settings schema 'org.gnome.settings-daemon.plugins.xsettings'
does not contain a key named 'antialiasing'
when run on a newer host — a GSettings schema mismatch from the old build
environment, not a documented Wayland-specific crash. GDK_BACKEND=x11 was reported
as a workaround for that specific error, not for GTK/Wayland instability in general.
The issue is closed and has 3 comments total.
Concrete impact of the current unconditional workaround
Observed with a Tauri 2 app (Alethe,
AppImage build) on Arch Linux + Hyprland + NVIDIA proprietary driver
(nvidia-open 610.57.04):
- With the plugin's default
GDK_BACKEND=x11: WebKitWebProcess sustained
~20-30% CPU while nvidia-smi showed ~0% GPU usage for the process (i.e., software
rendering via XWayland).
- Removing that one line (forcing native Wayland instead) fixed it — GPU-accelerated
rendering resumed, CPU usage dropped, confirmed under real interactive use, not just
idle measurement.
This isn't specific to Alethe — any Tauri (or other linuxdeploy-based) app shipped as
an AppImage inherits this hook, so every NVIDIA + Wayland user of any such app is
paying this cost by default.
Ask
Given the cited crash was narrow (an old-Ubuntu-build GSettings mismatch, already
closed) and forcing X11 has a real, measurable cost on the (now much more common)
NVIDIA + Wayland combination, could this be reconsidered? A few options that seem
reasonable, roughly in order of how much I'd guess they cost to implement:
- Make it overridable via an env var the packaging pipeline can set (e.g., only
export GDK_BACKEND=x11 if LINUXDEPLOY_GTK_FORCE_X11 isn't explicitly set to 0).
- Detect the actual failure condition (the GSettings schema lookup) instead of
blanket-forcing X11 for everyone regardless of whether they'd hit it.
- At minimum, revisit whether this is still needed at all — the original report is
from an ubuntu:20.04 build image; app builds are increasingly on newer bases
(Alethe's own CI already builds on ubuntu-22.04) where the schema mismatch may
not reproduce.
Happy to help test a change if useful — I don't have a Wayland-crash repro on hand
(I removed the line and things have been solid), but I can verify a conditional/opt-out
version doesn't regress the X11 path either.
Environment
- Distro: Arch Linux
- Compositor: Hyprland 0.56.2 (wlroots-based)
- GPU: NVIDIA GeForce RTX 3070,
nvidia-open 610.57.04
- Tauri app tested: Alethe 1.5.0 (AppImage), webkit2gtk 4.1
Summary
linuxdeploy-plugin-gtk.shunconditionally setsexport GDK_BACKEND=x11, citing"Crash with Wayland backend on Wayland".
The linked justification (tauri-apps/tauri#8541) is actually about something narrower
than a Wayland crash, and forcing X11 for every app built with this plugin causes a
real regression on modern NVIDIA + Wayland systems: WebKitGTK falls back to
unaccelerated software rendering, and the app's WebProcess sits at sustained high CPU
for no reason.
What the cited issue (tauri#8541) actually says
tauri-apps/tauri#8541 is titled
"Run AppImage: GLib-GIO-ERROR Settings schema error". The actual bug: an AppImage
built inside an
ubuntu:20.04container crashed withwhen run on a newer host — a GSettings schema mismatch from the old build
environment, not a documented Wayland-specific crash.
GDK_BACKEND=x11was reportedas a workaround for that specific error, not for GTK/Wayland instability in general.
The issue is closed and has 3 comments total.
Concrete impact of the current unconditional workaround
Observed with a Tauri 2 app (Alethe,
AppImage build) on Arch Linux + Hyprland + NVIDIA proprietary driver
(
nvidia-open610.57.04):GDK_BACKEND=x11:WebKitWebProcesssustained~20-30% CPU while
nvidia-smishowed ~0% GPU usage for the process (i.e., softwarerendering via XWayland).
rendering resumed, CPU usage dropped, confirmed under real interactive use, not just
idle measurement.
This isn't specific to Alethe — any Tauri (or other linuxdeploy-based) app shipped as
an AppImage inherits this hook, so every NVIDIA + Wayland user of any such app is
paying this cost by default.
Ask
Given the cited crash was narrow (an old-Ubuntu-build GSettings mismatch, already
closed) and forcing X11 has a real, measurable cost on the (now much more common)
NVIDIA + Wayland combination, could this be reconsidered? A few options that seem
reasonable, roughly in order of how much I'd guess they cost to implement:
export GDK_BACKEND=x11ifLINUXDEPLOY_GTK_FORCE_X11isn't explicitly set to0).blanket-forcing X11 for everyone regardless of whether they'd hit it.
from an
ubuntu:20.04build image; app builds are increasingly on newer bases(Alethe's own CI already builds on
ubuntu-22.04) where the schema mismatch maynot reproduce.
Happy to help test a change if useful — I don't have a Wayland-crash repro on hand
(I removed the line and things have been solid), but I can verify a conditional/opt-out
version doesn't regress the X11 path either.
Environment
nvidia-open610.57.04