Skip to content

[Bug] Failed to create GBM buffer of size 800x600: Invalid argument | Error on Arch Linux with Tauri #26

@airvzxf

Description

@airvzxf

Error

Hello team,

I am encountering a rendering issue when running a Tauri application on Arch Linux (bun run tauri dev or bun run tauri build). The development server starts correctly, and the web content is accessible via http://localhost:1420/, but the native desktop window is completely blank (white screen).

The terminal shows the following error message:

Failed to create GBM buffer of size 800x600: Invalid argument

Error message and blank window

Error explanation

Gemini 2.5 Pro | https://gemini.google.com/share/c6456d08358e

Here is a breakdown of the issue, its likely causes, and the workarounds I've found, based on some troubleshooting.

What the Error Means

The error Failed to create GBM buffer: Invalid argument points to a problem within the graphics rendering stack on Linux.

  • GBM (Generic Buffer Management) is an API used by Mesa (the open-source graphics driver stack) to manage memory buffers for hardware-accelerated rendering.
  • Tauri's web renderer on Linux, WebKitGTK, attempts to use this API to leverage the GPU for drawing the UI.
  • The error message indicates that WebKitGTK is passing parameters to the graphics driver that are considered invalid or are unsupported, causing the hardware-accelerated rendering to fail.
  • The fact that the web view works perfectly when accessed directly via localhost confirms that the web application code (HTML/CSS/JS) is not the problem. The issue lies exclusively in the native rendering layer that is supposed to draw the web content into a system window.

Common Causes

This issue is typically caused by an incompatibility between different parts of the graphics stack:

  1. Graphics Driver Incompatibility: A mismatch between the version of WebKitGTK used by Tauri, the system's Mesa version, and the specific kernel driver for the GPU (e.g., Intel, AMD, NVIDIA).
  2. Display Server Issues (Wayland vs. X11): WebKitGTK's hardware acceleration can sometimes have compatibility issues with Wayland, which is becoming the default display server on many modern Linux distributions. The APIs can be less mature or stable than the traditional X11 ones.
  3. Older Hardware: The GPU may not fully support the specific hardware acceleration features that WebKitGTK is attempting to use by default.

Solution

For me, the solution was the first option: “Disable WebKit's Compositing Mode (Successful Workaround)”.

Solutions and Workarounds (from most to least likely)

I tested several solutions, and the following is a prioritized list of what I found.

1. Disable WebKit's Compositing Mode (Successful Workaround)

This was the solution that fixed the issue. By setting the WEBKIT_DISABLE_COMPOSITING_MODE environment variable, WebKit is forced to use a simpler and more broadly compatible rendering path. This seems to avoid the problematic GBM call without completely disabling hardware acceleration.

Command:

WEBKIT_DISABLE_COMPOSITING_MODE=1 bun run tauri dev

This successfully rendered the application in the native window. This appears to be the most effective and direct workaround.

You can add to the package.json.

// package.json
"scripts": {
  "dev": "bun run tauri dev",
  "tauri": "tauri",
  // Modify the tauri scripot to include the environment variable
  "tauri:dev": "WEBKIT_DISABLE_COMPOSITING_MODE=1 bun run tauri dev"
}

2. Force the GDK Backend to X11

This is a potential solution for users running a Wayland session. Forcing the application to use the XWayland compatibility layer can often resolve rendering issues.

How to check session type:

echo $XDG_SESSION_TYPE 
# Outputs 'wayland' or 'x11'

Command to force X11:

GDK_BACKEND=x11 bun run tauri dev

Combine:

WEBKIT_DISABLE_COMPOSITING_MODE=1 GDK_BACKEND=x11 bun run tauri dev

3. Force Software Rendering (Diagnostic Step)

As a last resort for troubleshooting, forcing the entire application to use software rendering bypasses the GPU drivers entirely. While this would likely fix the blank window, it comes at a significant performance cost. It's useful primarily to confirm that the issue is indeed within the hardware acceleration stack.

Command:

LIBGL_ALWAYS_SOFTWARE=1 bun run tauri dev

Local specs

OS: Arch Linux
Kernel: x86_64 Linux 6.15.3-arch1-1
Packages: 1282
Shell: bash 5.2.37
Resolution: 1920x1080
WM: OpenBox
WM Theme: Clearlooks
GTK Theme: Adwaita [GTK3]
Disk: 498G / 1.8T (30%)
CPU: Intel Core i7-7820HK @ 8x 3.9GHz [51.0°C]
GPU: NVIDIA GeForce GTX 1080
RAM: 9401MiB / 64251MiB

Claudia build on commit abe0891 (HEAD -> main, origin/main, origin/HEAD).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions