Linux: X BadWindow on X_ConfigureWindow after CEF init (NVIDIA proprietary driver + Wayland)

[ElioNeto]

Issue imported from tinyhumansai/openhuman#2094
Created at: unknown

---

Summary

After CEF successfully creates the main browser context (browser_id=1 origin=http://tauri.localhost/) and installs notification shims, the process aborts with an X11 protocol error during window configuration:

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  12 (X_ConfigureWindow)
  Resource id in failed request:  0xNN00001
  Serial number of failed request:  7
  Current serial number in output stream:  11

The crash happens after [cef-render-notify] installed shims browser_id=1 is logged. A second browser_id=2 origin=about:blank (the prewarm/helper) is even created before the process actually dies, suggesting this is the GTK parent window failing to be configured rather than CEF itself.

This is reproducible across reboots and is independent of every documented Linux flag combination I could find. I believe this is distinct from tinyhumansai#2001 (which is library-init failures on Intel+Hyprland) and from tinyhumansai#2078 (which is the earlier tauri_runtime_cef::CefRuntime::init assertion).

Environment

Distro	Pop!_OS 24.04 LTS (Ubuntu noble base)
Kernel	6.18.7-76061807-generic
Session	Wayland (XDG_SESSION_TYPE=wayland, WAYLAND_DISPLAY=wayland-1)
Compositor	COSMIC (Pop!_OS default)
GPU	NVIDIA RTX 4070 Ti, proprietary driver 580.159.03 (monitors connected here)
Secondary GPU	AMD Raphael iGPU (Ryzen 9 7950X3D onboard, idle)
GLIBC	2.39
OpenHuman	v0.53.49 built from main (HEAD 579addf0 plus one local patch — see below)
Node	24.15.0
Rust	1.94.1
CEF	146.0.9 (auto-downloaded by cargo tauri dev)

Not using the AppImage installer — built from source because #2088 (bundled libm.so.6 GLIBC 2.35 < system libsqlite3 GLIBC 2.38 requirement) prevented the AppImage from launching at all on this box.

Steps to reproduce

# 1. Standard build-from-source per gitbooks/developing/getting-set-up.md
git clone https://github.com/tinyhumansai/openhuman.git
cd openhuman
git submodule update --init --recursive
pnpm install
cp .env.example .env
cp app/.env.example app/.env.local
pnpm config set script-shell /bin/bash    # otherwise dash chokes on `source` in dev:app

# 2. Run the Linux dev flow from gitbooks/developing/getting-set-up.md
export CEF_PATH="$HOME/Library/Caches/tauri-cef"
export LD_LIBRARY_PATH="$CEF_PATH/146.0.9/cef_linux_x86_64:$LD_LIBRARY_PATH"
export PATH="$(pwd)/.cache/cargo-install/bin:$PATH"
source scripts/load-dotenv.sh
cargo tauri dev -- -- --no-sandbox

The build completes cleanly; the binary launches; the crash above fires within ~1 second of the window being created.

Full log (relevant tail)

[startup] platform: arch=x86_64 os=linux os_version=n/a
[cef-profile] configured CEF cache user=local path=/home/USER/.openhuman/users/local/cef
[fake-camera] reusing cached mascot Y4M
[cef-startup] fake-camera y4m path=...
[cef-startup] Linux detected: adding --disable-gpu, --disable-gpu-compositing, and --ozone-platform-hint=auto (...)
[ERROR:media/gpu/vaapi/vaapi_wrapper.cc:1640] vaInitialize failed: unknown libva error
[ERROR:chrome/browser/net/system_network_context_manager.cc:965] Cannot use V8 Proxy resolver in single process mode.
DevTools listening on ws://127.0.0.1:19222/devtools/browser/...
data directory is not yet implemented
[webview_apis] server listening on 127.0.0.1:37833 (OS-assigned ephemeral)
[webview_apis] bridge ready on port 37833
[tray] deferring tray setup to RunEvent::Ready
[app] RunEvent::Ready — GTK initialized, setting up tray
[tray] skipping tray setup on linux: tray menu creation still panics inside GTK during packaged runs
[cef-render-notify] on_context_created browser_id=1 origin=http://tauri.localhost/
[cef-render-notify] installed shims browser_id=1 origin=http://tauri.localhost/
data directory is not yet implemented
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  12 (X_ConfigureWindow)
  Resource id in failed request:  0x7200001
  Serial number of failed request:  7
  Current serial number in output stream:  11
[cef-render-notify] on_context_created browser_id=2 origin=about:blank
ELIFECYCLE  Command failed.

Note: [cef-render-notify] on_context_created browser_id=2 origin=about:blank appears AFTER the X error, suggesting the BadWindow happens during a GTK→CEF window-configuration call while CEF subprocesses keep running until Xlib's default error handler aborts the process.

What I ruled out

Reproducible at the same step regardless of:

Variant	Result
Default pnpm dev:app	X BadWindow
--no-sandbox (per gitbooks/developing/getting-set-up.md "Running on Linux cloud VMs")	X BadWindow
--single-process (collapses CEF helper procs)	X BadWindow (gets further — browser_id=2 is created before death)
--ozone-platform-hint=auto + --enable-features=UseOzonePlatform (patched into append_platform_cef_gpu_workarounds)	X BadWindow
GDK_BACKEND=wayland (force GTK Wayland-native)	X BadWindow
GDK_BACKEND=x11 (force GTK X11)	X BadWindow
Combinations of all of the above	X BadWindow
After fresh reboot (clean compositor state)	X BadWindow
With and without DRI_PRIME / Mesa EGL overrides routing rendering to AMD iGPU	X BadWindow

The crash is deterministic and identical across all attempts.

Diagnosis (best guess)

The X_ConfigureWindow (opcode 12) target is the GTK parent window that Tauri creates to host the CEF webview. After RunEvent::Ready fires and the tray-setup code short-circuits on Linux (see vendor/tauri-cef/.../lib.rs — tray menu creation still panics inside GTK during packaged runs), something tries to XConfigureWindow the parent and the window ID is invalid by then.

This appears specific to NVIDIA's proprietary X server implementation under XWayland. Mesa-only setups (the AMD-on-Wayland reports in tinyhumansai#2038, tinyhumansai#1880) hit different EGL/NSS errors but not this X protocol error.

Workaround in use

Run OpenHuman in "cloud" mode against a local externally-started core, so the Tauri/CEF shell is completely bypassed:

# Build the core CLI separately
cargo build --bin openhuman-core

# Run it
./target/debug/openhuman-core run --port 7788
# (Writes a bearer token to ~/.openhuman/core.token)

# In a second terminal, run Vite UI
pnpm dev

# Open Brave/Chrome at http://localhost:1420
# In the BootCheckGate picker, select "Cloud" mode:
#   URL:   http://127.0.0.1:7788/rpc
#   Token: <contents of ~/.openhuman/core.token>

This works perfectly. The frontend's isTauri() guards correctly disable native-only features (tray, daemon lifecycle, auto-update, Meet mascot-camera, per-account isolated webviews) and the agent/memory/skills/MCP core all function normally.

It would be useful if the Linux installer flow documented this fallback for users on NVIDIA proprietary driver setups, since the Tauri-CEF path is currently inoperable on this hardware configuration.

Local patch I applied (not the fix, just an attempt)

app/src-tauri/src/lib.rs:

     if os == "linux" {
         args.push(("--disable-gpu", None));
         args.push(("--disable-gpu-compositing", None));
+        args.push(("--ozone-platform-hint", Some("auto")));
+        args.push(("--enable-features", Some("UseOzonePlatform")));
         log::info!(
-            "[cef-startup] Linux detected: adding --disable-gpu and --disable-gpu-compositing (issue #1697)"
+            "[cef-startup] Linux detected: adding --disable-gpu, --disable-gpu-compositing, and --ozone-platform-hint=auto (...)"
         );
     }

It did not fix the crash on this box but seemed reasonable to log here in case it helps other Linux users.

Things that might help debug upstream

• Is there a known interaction between tauri-runtime-cef window-configure timing and NVIDIA's GLX/X11 implementation? Especially in combination with the tray-skip code path (the [tray] skipping tray setup on linux: tray menu creation still panics inside GTK during packaged runs warning)?
• Could the parent GTK window be freed/destroyed by the tray-skip path while a configure request is still in flight?
• Would running the Tauri shell with tauri-plugin-window-state disabled, or with an explicit pre-sized window (so no resize/configure round-trip is needed) sidestep this?

Happy to test patches or collect any logs / GDB backtraces you'd like.