White/blank screen on launch — Intel iGPU (Iris Xe) + Wayland, bundled EGL init fails (EGL_BAD_PARAMETER)

[1731300623]

White/Black screen on launch — Intel iGPU (Iris Xe) + Wayland, EGL init fails

Summary

LiveAgent v1.1.2 AppImage launches its window but renders a white/blank screen (no UI content). The app's MCP backend starts normally, but the GPU/renderer subprocess fails EGL initialization and aborts. Reproducible on a machine with only integrated graphics (Intel Iris Xe) under Wayland.

Environment

• LiveAgent: v1.1.2 (LiveAgent-v1.1.2-Linux-x86_64.AppImage)
• OS: CachyOS (Arch-derived), x86_64
• Kernel: 7.1.3-2-cachyos
• Compositor/Session: niri (Wayland), XDG_SESSION_TYPE=wayland
• GPU: Intel TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) — integrated only, no dGPU
• Mesa: 3:26.1.4-1
• webkit2gtk-4.1: 2.52.5-2
• OpenGL renderer (host): Mesa Intel(R) Iris(R) Xe Graphics (TGL GT2), GL 4.6 — host OpenGL is healthy.

Reproduction

1. Download LiveAgent-v1.1.2-Linux-x86_64.AppImage on an Intel-iGPU-only Wayland machine.
2. chmod +x and run ./LiveAgent-v1.1.2-Linux-x86_64.AppImage.
3. Window appears but stays blank (white/black). Backend logs show the error below.

Logs

[MCP][ELEMENT_PICKER][INFO] Element picker event listeners registered
[MCP][PLUGIN][INFO] MCP Bridge plugin initialized for 'LiveAgent' (com.xiaofei.liveagent) on 0.0.0.0:9223
[MCP][WS_SERVER][INFO] WebSocket server listening on: 0.0.0.0:9223
Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...

The first three lines (MCP) appear immediately and the WebSocket server listens, so the main process is fine. The EGL_BAD_PARAMETER line comes from the bundled WebKit/ANGLE renderer subprocess, which then aborts — leaving the webview with no rendered content.

What I've already tried (none of them fix the blank screen)

All of the following leave the EGL_BAD_PARAMETER line unchanged and the window blank:

• WEBKIT_DISABLE_DMABUF_RENDERER=1
• WEBKIT_DISABLE_COMPOSITING=1
• GDK_BACKEND=wayland,x11
• Full software-rendering bundle: LIBGL_ALWAYS_SOFTWARE=1 GALLIUM_DRIVER=llvmpipe WEBKIT_DISABLE_DMABUF_RENDERER=1 WEBKIT_DISABLE_COMPOSITING=1
• Tauri/Tauri-related env vars are not exposed by the AppImage's runtime args.

So this does not appear to be the usual DMABUF/compositing toggle path; the EGL failure happens earlier and survives even llvmpipe fallback, which suggests the bundled ANGLE/EGL in the AppImage can't get a working EGLDisplay on this iGPU/Wayland combo at all.

Notes

• Host EGL/OpenGL itself is fine: glxinfo reports the Iris Xe renderer and GL 4.6, and other Wayland GL apps work.
• Likely relevant: this is an integrated-graphics-only machine. Workarounds that help on hybrid/dGPU systems (PRIME-related) don't apply here.
• AppImage internal libraries may be statically bundling an ANGLE/mesa combo that conflicts with the host Mesa 26.1 stack on this GPU.

Question / Ask

Is there a known flag or build option to force a working renderer on Intel iGPU + Wayland, or could the AppImage bundle an EGL/ANGLE build that initializes on Iris Xe? Happy to provide more traces (--appimage-extract and ldd the bundled libs, WAYLAND_DEBUG=1, etc.) if useful.

[su-fen]

Thanks for the excellent report — the traces you ran already pointed at the right layer, and you were right that this isn't the usual DMABUF/compositing toggle path.

Root cause (confirmed)

We unpacked the v1.1.2 AppImage: Tauri's default AppImage bundling sweeps the build machine's (Ubuntu 24.04) libwayland-client.so.0 1.22 — plus libwayland-cursor/egl/server — into usr/lib, and AppRun prepends that directory to LD_LIBRARY_PATH. Your host's Mesa 26.1 EGL stack then initializes its Wayland platform against that older bundled libwayland-client, and eglGetDisplay(EGL_DEFAULT_DISPLAY) fails with EGL_BAD_PARAMETER, so WebKit's renderer subprocess aborts before any renderer/driver selection happens.

That's also why none of the env toggles changed anything: WEBKIT_DISABLE_DMABUF_RENDERER, WEBKIT_DISABLE_COMPOSITING, and even the full llvmpipe bundle all act at the renderer/driver layer, but llvmpipe still goes through the same Wayland-platform EGL init against the same mismatched bundled libwayland. It's not Iris-Xe-specific — it hits any host with Mesa ≥ 25. Upstream tracking: tauri-apps/tauri#15665 (libwayland must always come from the host so it matches the host's Mesa).

Workarounds for v1.1.2 (any one of these)

1. Preload the host libwayland over the bundled copy:

   LD_PRELOAD=/usr/lib/libwayland-client.so.0 ./LiveAgent-v1.1.2-Linux-x86_64.AppImage

2. Extract once and strip the bundled wayland libs:

   ./LiveAgent-v1.1.2-Linux-x86_64.AppImage --appimage-extract
   rm squashfs-root/usr/lib/libwayland-*.so*
   ./squashfs-root/AppRun

3. Use the .deb/.rpm payload instead of the AppImage — those link your system webkit2gtk (2.52.5 on your box, which is healthy) and bundle no libraries. On Arch, debtap works, or just extract data.tar under /opt.

Fix

Tauri has no supported "exclude libraries" knob yet, so we've added a post-processing step to the release pipeline that strips libwayland-* from the AppImage and re-signs it. It also neutralizes a GST_PLUGIN_SYSTEM_PATH(_1_0) export baked into AppRun that points at a directory we never populate — that one silently disables GStreamer plugin discovery and can leave a poisoned empty registry in ~/.cache/gstreamer-1.0 that affects other apps, so if you've launched the AppImage a few times you may want to rm -rf ~/.cache/gstreamer-1.0 once. The next release's AppImage should work out of the box on Mesa ≥ 25 hosts.

If you get a chance, could you confirm that workaround 1 or 2 brings the window up on the niri/Iris Xe machine? That would rule out a second issue hiding behind this one.

[1731300623]

Confirmed — workaround 1 works on the niri/Iris Xe machine.

With the AppImage launched directly: window appears but stays blank, with the Could not create default EGL display: EGL_BAD_PARAMETER. Aborting... line in the log.

With host libwayland preloaded:

LD_PRELOAD=/usr/lib/libwayland-client.so.0 ./LiveAgent-v1.1.2-Linux-x86_64.AppImage

The EGL_BAD_PARAMETER ... Aborting line is gone entirely from the startup log — only the normal MCP bootstrap lines remain:

[MCP][ELEMENT_PICKER][INFO] Element picker event listeners registered
[MCP][PLUGIN][INFO] MCP Bridge plugin initialized for 'LiveAgent' (com.xiaofei.liveagent) on 0.0.0.0:9223
[MCP][WS_SERVER][INFO] WebSocket server listening on: 0.0.0.0:9223

And the window now actually renders content instead of staying blank.

For reference, host libwayland here is 1.25.0 vs the bundled 1.22, host Mesa 26.1.4, Intel Iris Xe (TGL GT2), Wayland/niri.

Also done per your note: cleaned ~/.cache/gstreamer-1.0 (registry had been written there from prior failed launches), so no poisoned registry left for other apps.

I've baked the LD_PRELOAD of the host libwayland-client.so.0 into a local launcher so normal launches pick it up until the next release's re-signed AppImage lands. Thanks for the fast, thorough root-cause write-up — the libwayland must always come from the host framing matches what we see exactly.

[1731300623]

Update: just upgraded to v1.1.3 (released today) and tested on the same niri/Iris Xe + Mesa 26.1 host.

The LD_PRELOAD workaround of the host libwayland-client.so.0 still works (window renders, EGL_BAD_PARAMETER ... Aborting line gone).

But raw AppImage launch still reproduces the issue on v1.1.3:

[MCP][ELEMENT_PICKER][INFO] Element picker event listeners registered
[MCP][PLUGIN][INFO] MCP Bridge plugin initialized for 'LiveAgent' (com.xiaofei.liveagent) on 0.0.0.0:9225
[MCP][WS_SERVER][INFO] WebSocket server listening on: 0.0.0.0:9225
Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...

So the bundled libwayland-* strip + re-sign post-processing step you described in your previous reply doesn't appear to have landed in v1.1.3's AppImage yet. Just flagging so you can confirm whether the fix is tracked for a later release. I'll keep the LD_PRELOAD launcher until then — thanks again.