fix: disable WebKit DMABuf renderer on Linux#148
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a workaround for Linux WebKit DMABUF renderer issues by setting the WEBKIT_DISABLE_DMABUF_RENDERER environment variable to 1 if it is not already set. This is executed at the start of the application run process on Linux. Unit tests are also added to verify this behavior. Feedback suggests wrapping the std::env::set_var call in an unsafe block to comply with Rust 1.81.0+ and Rust 2024 edition requirements, as modifying environment variables can cause data races in multi-threaded environments.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| if should_set_webkit_dmabuf_renderer_env( | ||
| std::env::var_os(WEBKIT_DISABLE_DMABUF_RENDERER_ENV).as_deref(), | ||
| ) { | ||
| std::env::set_var(WEBKIT_DISABLE_DMABUF_RENDERER_ENV, "1"); |
There was a problem hiding this comment.
Starting in Rust 1.81.0 (and enforced in the Rust 2024 edition), std::env::set_var is marked as unsafe because modifying environment variables in a multi-threaded environment can lead to data races and undefined behavior.
To ensure compatibility with newer Rust editions and prevent compilation errors or deprecation warnings, wrap the call in an unsafe block. Since this function is called at the very beginning of main before any other threads are spawned, it is safe to do so.
// SAFETY: This is called at the very beginning of the application's execution
// before any other threads are spawned, ensuring no data races occur.
unsafe {
std::env::set_var(WEBKIT_DISABLE_DMABUF_RENDERER_ENV, "1");
}
|
@sourcery-ai review |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 1 issue
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="src-tauri/src/app_runtime.rs" line_range="22-31" />
<code_context>
+ existing_value.is_none() && wayland_display.is_some()
+}
+
+#[cfg(target_os = "linux")]
+fn configure_linux_webkit_workarounds() {
+ if should_set_webkit_dmabuf_renderer_env(
</code_context>
<issue_to_address>
**suggestion:** Consider surfacing when the workaround is applied to aid troubleshooting
Because this env var can materially change rendering on Linux, it would help troubleshooting if we logged when the workaround is applied (e.g., right after or inside `configure_linux_webkit_workarounds`). That way, differences in WebKit/Wayland behavior tied to this flag are easier to diagnose.
Suggested implementation:
```rust
#[cfg(target_os = "linux")]
fn configure_linux_webkit_workarounds() {
if should_set_webkit_dmabuf_renderer_env(
std::env::var_os(WEBKIT_DISABLE_DMABUF_RENDERER_ENV).as_deref(),
std::env::var_os(WAYLAND_DISPLAY_ENV).as_deref(),
) {
std::env::set_var(WEBKIT_DISABLE_DMABUF_RENDERER_ENV, "1");
tracing::info!(
"Applied Linux WebKit workaround: set {}=1 (Wayland display detected, no existing value)",
WEBKIT_DISABLE_DMABUF_RENDERER_ENV
);
}
}
```
1. Ensure that `tracing` (or your chosen logging crate) is available and initialized in the application startup path so that this log line is emitted (e.g., via `tracing_subscriber`).
2. If the project uses a different logging macro (such as `log::info!` or a custom logger), replace `tracing::info!` with the appropriate macro to match the existing logging conventions.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
|
@sourcery-ai review |
1 participant
Summary
Fixes #147.
On Linux Wayland sessions, set
WEBKIT_DISABLE_DMABUF_RENDERER=1before Tauri creates the WebKitGTK webview. This works around a known WebKitGTK/Tauri upstream issue where Wayland + NVIDIA environments can fail to start or render with:The variable is only set when:
WAYLAND_DISPLAYis present, so X11 Linux sessions are left unchanged.WEBKIT_DISABLE_DMABUF_RENDERERis not already provided, so manual overrides such asWEBKIT_DISABLE_DMABUF_RENDERER=0remain possible.Context
The reported Fedora KDE/Wayland/NVIDIA crash matches upstream reports:
WebKitGTK itself reads
WEBKIT_DISABLE_DMABUF_RENDERERinAcceleratedBackingStore.cpp, so this is an application-level startup workaround for an upstream rendering path rather than an AstrBot backend/WebUI change.Changes
tauri::Builder::default().WAYLAND_DISPLAY.WEBKIT_DISABLE_DMABUF_RENDERERvalues.Verification
rtk cargo fmt --all --checkrtk cargo test app_runtime::tests::webkit_dmabuf_workaround_is_set_only_for_wayland_without_overridertk cargo testNote: one full
cargo testrun initially hit an existing-looking concurrent-state failure indesktop_settings::tests::write_desktop_setting_preserves_unknown_fields; that specific test passed when rerun alone, and the full suite passed on the next run.Notes
Disabling WebKitGTK's DMABuf renderer can reduce rendering performance on some Linux systems, so the workaround is limited to Wayland sessions and still allows users to override the variable explicitly.
Summary by Sourcery
Apply a Linux-only startup workaround that configures WebKitGTK to avoid DMABuf rendering issues on Wayland sessions.
Bug Fixes:
Tests: