github / github/app

Linux AppImage forces GDK_BACKEND=x11 and bundles a conflicting glib, blocking native Wayland + GPU compositing (.deb of same version is unaffected)

Open
#3,060 7 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.