Linux AppImage forces GDK_BACKEND=x11 and bundles a conflicting glib, blocking native Wayland + GPU compositing (.deb of same version is unaffected)
- Dominant language
- No language data
- Stars
- 2.1k
- Forks
- 153
- PR merge metrics
- No merged PRs in 30d
Description
### Short summary
The Linux **AppImage** unconditionally forces `GDK_BACKEND=x11` in its bundled AppRun hook, so the app can never run on native Wayland — even when the user explicitly sets `GDK_BACKEND=wayland`. The same AppImage also bundles a `glib`/`gvfs` build that conflicts with the host's, breaking GIO module loading and the dconf `gsettings` backend.
The **`.deb` of the same version has neither problem**. Switching packaging alone (identical version, same machine, same session) moved the app from XWayland + software compositing to native Wayland + GPU compositing.
This is likely the underlying cause of #2646 ("the AppImage is laggy af", where the reporter also found a Wayland flag helped) and is related to #1324 / #335.
### Affected version or release
`1.1.11` (AppImage and `.deb` compared side by side; hook text also present in earlier builds)
### Installation context
AppImage (compared against the `.deb`)
### What happened?
**1. AppImage hard-codes the X11 backend, silently overriding the user**
`squashfs-root/apprun-hooks/linuxdeploy-plugin-gtk.sh` line 9:
```bash
export GDK_BACKEND=x11 # Crash with Wayland backend on Wayland - We tested it without it and ended up with this: https://github.com/tauri-apps/tauri/issues/8541
```
Because `AppRun` sources this hook *after* the user's environment is set, `env GDK_BACKEND=wayland ./GitHub-Copilot.AppImage` has **no effect** — the hook overwrites it. Verified on the running process:
```
$ tr '\0' '\n' < /proc/$PID/environ | grep GDK_BACKEND
GDK_BACKEND=x11 # despite launching with GDK_BACKEND=wayland
$ xlsclients | grep -c github
1 # running as an XWayland client
```
I understand this was deliberate (tauri-apps/tauri#8541). The issue is that it is *unconditional* and provides no opt-out, so users on working configurations cannot get native Wayland. A minimal fix preserves the safe default while allowing an override:
```bash
export GDK_BACKEND="${GDK_BACKEND:-x11}"
```
**2. Bundled glib conflicts with host GIO modules**
The AppImage sets `GIO_EXTRA_MODULES` / `GTK_PATH` to bundled paths while the host's modules remain on the search path, producing on every launch:
```
/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so
/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so: undefined symbol: g_assertion_message_cmpint
```
Side effect worth flagging: with `libdconfsettings.so` failing to load, **`gsettings` silently returns compiled-in schema defaults instead of the user's real values** — inside the AppImage environment, `text-scaling-factor` reported `1.0` when the user's actual setting was `1.25`, and `experimental-features` reported `[]` when fractional scaling was enabled. Any in-app logic reading GSettings for scaling/theme is reading wrong values under the AppImage.
**3. Measured impact (same version 1.1.11, same machine, same session)**
| | AppImage | `.deb` |
| --- | --- | --- |
| Display backend | XWayland (forced) | **native Wayland** |
| GPU compositing | software readback | **DMA-BUF / `libEGL_mesa` + `libgbm`** |
| WebKit | bundled | system `2.52.3` |
| GIO/dconf errors | yes | none |
Renderer CPU while scrolling, measured by delta-sampling `utime+stime` from `/proc//stat` (not `ps %CPU`, which reports a lifetime average):
- AppImage default: **~85% of one core**
- AppImage with `WEBKIT_DISABLE_DMABUF_RENDERER=0`: **~70%**
- `.deb`, idle after settling: **~6-13%**
Scrolling is subjectively much smoother on the `.deb`. Native Wayland additionally restores pixel-precise scroll events, where XWayland delivers discrete button-4/5 clicks.
**Secondary note:** the binary itself sets `WEBKIT_DISABLE_DMABUF_RENDERER=1` (string present in both AppImage and `.deb` binaries). Overriding it to `0` was worth roughly 15 percentage points of renderer CPU on Intel/Mesa. If that default exists for stability on specific drivers, it would help to gate it (e.g. driver allowlist) or document an opt-out, rather than applying it everywhere.
### Steps to reproduce
1. On a Wayland session, launch the AppImage with an explicit override: `env GDK_BACKEND=wayland ./GitHub-Copilot-linux-x64.AppImage`
2. `tr '\0' '\n' < /proc/$(pgrep -x github)/environ | grep GDK_BACKEND` → still `x11`
3. `xlsclients | grep github` → present, i.e. running under XWayland
4. Observe the `Failed to load module` / `undefined symbol` errors in stdout
5. Install the `.deb` of the same version and repeat: no `GDK_BACKEND` forced, absent from `xlsclients`, no GIO errors
### Expected behavior
- The AppImage should respect a caller-supplied `GDK_BACKEND` (defaulting to `x11` if unset), so users on working setups can opt into native Wayland.
- Bundled glib/GIO should not conflict with host modules, so `gsettings` returns real user values.
- Ideally the AppImage should reach parity with the `.deb` on backend and compositing.
### Environment
| Field | Value |
| --- | --- |
| App version | 1.1.11 (AppImage and .deb) |
| OS | Ubuntu 24.04.4 LTS |
| Desktop | GNOME 46, Wayland session |
| GPU | Intel Iris Xe (i7-1365U), Mesa, `/dev/dri/renderD128` |
| System WebKitGTK | 2.52.3-0ubuntu0.24.04.1 |
| System glib | 2.80.0-6ubuntu3.8 |
| Display scaling | fractional 1.25 + text scaling 1.25 |
### Workaround for other users
Use the `.deb` instead of the AppImage on Wayland systems. To also enable GPU compositing:
```bash
WEBKIT_DISABLE_DMABUF_RENDERER=0 github
```
Contributor guide
Research direction
Start with squashfs-root/apprun-hooks/linuxdeploy-plugin-gtk.sh, then trace how the AppImage assembles its bundled glib/GIO paths. Reproduce the Wayland launch and GIO errors from the issue, comparing the AppImage with the same-version .deb. Done means a caller-supplied backend is preserved and the conflicting module errors no longer occur, with relevant packaging checks passing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux, shell
- Domain
- build-system, desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100