Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Linux: forced WEBKIT_DISABLE_DMABUF_RENDERER=1 makes the main window transparent on WebKitGTK 2.54 (only repainted regions show)

Đang mở
  • Có gì không ổn?
#2,624 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@AatmanAJ đang làm issue này rồi.

Từ ngày 15/10/2026.

  • #2628 của @AatmanAJ — đang mở

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
25/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
linux, rust, tauri
Lĩnh vực
desktop

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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:

https://github.com/CapSoftware/Cap/blob/83237e994efb1e9842933d279ae2b338549be545/apps/desktop/src-tauri/src/main.rs#L48-L51

#[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
  1. Debian 13, KDE Plasma 6.3 Wayland, WebKitGTK 2.54.0.
  2. Install Cap 0.6.0 (.deb) and launch it.
  3. 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=1
  • WEBKIT_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

Ngôn ngữ chính
Rust
Star
23.2k
Fork
2k
Merge trung bình
1 ngày 5 giờ
Pull request đã merge (30 ngày)
130

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của CapSoftware/Cap

Tất cả issue của CapSoftware/Cap

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.