Linux: forced WEBKIT_DISABLE_DMABUF_RENDERER=1 makes the main window transparent on WebKitGTK 2.54 (only repainted regions show)
I maintainer di solito rispondono entro 1 giorno
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 25/100
Direzione di ricerca
The forced variable is set unconditionally in apps/desktop/src-tauri/src/main.rs, lines 48-51, under a #[cfg(target_os = "linux")] block. Read that block, then check the linked PR #2628 before starting, since it is already open against this issue. Done means the variable is skipped when the user has already set it, and the window renders on WebKitGTK 2.54 without the shim.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Description
On Linux with WebKitGTK 2.54, Cap's main window is almost entirely invisible. The window exists (KWin reports it mapped, 330×395, not hidden/minimized), but only the regions that get repainted show up: a hovered button, a toggle being animated, etc. Everything else stays transparent, so you see the desktop through the window.
The cause is the unconditional override added for #1948:
#[cfg(target_os = "linux")]
unsafe {
std::env::set_var("WEBKIT_DISABLE_DMABUF_RENDERER", "1");
}
With WebKitGTK 2.54, disabling the DMABUF renderer on a transparent window makes WebKit repaint only the damaged areas, and the rest of the surface is never painted. Other Tauri projects hit the same regression on 2.54 (e.g. rogeriojunior31/vultures-ai#126, xnmp/tauri-explorer#1057).
Because the variable is overwritten with set_var, users can't opt out: running WEBKIT_DISABLE_DMABUF_RENDERER=0 Cap still yields WEBKIT_DISABLE_DMABUF_RENDERER=1 in the environment of Cap's WebKitWebProcess (checked via /proc/<pid>/environ).
Reproduction
- Debian 13, KDE Plasma 6.3 Wayland, WebKitGTK 2.54.0.
- Install Cap 0.6.0 (
.deb) and launch it. - The main window is transparent except for elements being hovered or animated.
What I tried
All of these still show the bug, because the forced variable stays in effect:
GDK_BACKEND=x11(XWayland)WEBKIT_DISABLE_COMPOSITING_MODE=1WEBKIT_SKIA_ENABLE_CPU_RENDERING=1- forcing Mesa EGL instead of NVIDIA (
__EGL_VENDOR_LIBRARY_FILENAMES=.../50_mesa.json) WEBKIT_FORCE_COMPOSITING_MODE=1
Workaround that fixes it: an LD_PRELOAD shim that turns setenv("WEBKIT_DISABLE_DMABUF_RENDERER", …) into a no-op. With the variable unset, the window renders fully and correctly on this machine.
#define _GNU_SOURCE
#include <dlfcn.h>
#include <string.h>
int setenv(const char *name, const char *value, int overwrite) {
static int (*real)(const char *, const char *, int);
if (!real) real = dlsym(RTLD_NEXT, "setenv");
if (name && strcmp(name, "WEBKIT_DISABLE_DMABUF_RENDERER") == 0) return 0;
return real(name, value, overwrite);
}
Suggested fix
At minimum, respect a value the user already set, so people can opt out without a shim:
#[cfg(target_os = "linux")]
if std::env::var_os("WEBKIT_DISABLE_DMABUF_RENDERER").is_none() {
unsafe { std::env::set_var("WEBKIT_DISABLE_DMABUF_RENDERER", "1"); }
}
Better still, don't apply the workaround by default on WebKitGTK ≥ 2.54 (or limit it to the configurations from #1948), since it now breaks rendering instead of fixing it.
Environment
- Cap 0.6.0 (
.deb) - Debian GNU/Linux 13 (trixie), kernel 6.12
- KDE Plasma / KWin 6.3.6, Wayland session
- libwebkit2gtk-4.1 2.54.0
- Hybrid GPU: Intel Raptor Lake UHD (i915) + NVIDIA RTX 4060 Laptop (driver 555.58.02)
Related: #1948, #1553
- Lingua principale
- Rust
- Stelle
- 23.2k
- Fork
- 2k
- Merge medio
- 1g 5h
- PR unite (30g)
- 130
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di CapSoftware/Cap
-
Web player intercepts ⌘⇧M and blocks Chrome profile-menu shortcutForse già presa @AatmanAJ l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 80/100
CapSoftware/Cap#2596 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
CapSoftware/Cap#2384 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Dashboard pagination causes full page reloads on self-hosted CapForse già presa @Dewin l’ha presa 29 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
CapSoftware/Cap#2305 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
CapSoftware/Cap#1714 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
macOS: main-thread panic in tauri-runtime-wry 2.8.1 freezes Cap mid Instant recording; the crashed recording then can't be recovered or reuploadedForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 18/100
CapSoftware/Cap#2606 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di CapSoftware/Cap
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
shep-pm/shep-kelpie#980 ·
I maintainer di solito rispondono entro 1 giorno
-
bug frontend rt sev-3
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
C-bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
-
[1.x Bug] run-operation --sql reports success but rolls back writes on transaction-capable adaptersApertatriage
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
dbt-labs/dbt#16784 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
area:cli bug good first issue priority:medium
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
rtk-ai/rtk#4615 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno