Linux AppImage forces GDK_BACKEND=x11 and bundles a conflicting glib, blocking native Wayland + GPU compositing (.deb of same version is unaffected)
- Ngôn ngữ chính
- Không có dữ liệu ngôn ngữ
- Star
- 2.1k
- Fork
- 153
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Mô tả
### 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
```
Hướng dẫn đóng góp
Hướng nghiên cứu
Bắt đầu với squashfs-root/apprun-hooks/linuxdeploy-plugin-gtk.sh, sau đó lần theo cách AppImage tập hợp các đường dẫn glib/GIO đi kèm. Tái hiện các lỗi khởi chạy Wayland và lỗi GIO từ issue, so sánh AppImage với .deb cùng phiên bản. Hoàn tất khi backend do bên gọi cung cấp được giữ nguyên, các lỗi mô-đun xung đột không còn xảy ra và các kiểm tra packaging liên quan đều đạt.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- linux, shell
- Lĩnh vực
- build-system, desktop
- Loại issue
- Lỗi
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức độ hoạt động
- Sôi nổi
- Độ rõ ràng
- Khá rõ ràng
- Mức phù hợp với người mới
- 48/100