Linux/X11: llvmpipe Vulkan window is transparent, GL renders on the same system

Reproduction steps

1. Use a Debian 12 x86_64 virtual desktop with an Xorg dummy display, KDE/KWin X11 compositing, and Mesa 22.3.6/LLVM 15.0.6 software rendering (no hardware Vulkan adapter exposed to the session).
2. Install the official Zed 1.26.2 stable x86_64 release and run zed --new.
3. Observe the window's contents. Repeat after a fresh installation: the same behavior reproduces.
4. As a same-binary control, start a fresh Zed process with Vulkan ICD discovery pointed at a nonexistent JSON file (also use a fresh --user-data-dir so the client cannot reuse an existing process):

VK_DRIVER_FILES=/nonexistent/zed-vulkan-disabled.json VK_ICD_FILENAMES=/nonexistent/zed-vulkan-disabled.json zed --user-data-dir /tmp/zed-gl-control --new

Current vs. Expected behavior

Current: With default settings, Zed's X11 window is mapped and consumes input, but it is fully transparent: content from other windows behind it is visible instead of the editor. The log says Rendered first frame, but that message alone is not evidence that pixels were displayed. The problem reproduced on two separate launches and after reinstalling the official package.

Control: On the same machine with Vulkan ICDs hidden, the official unchanged binary selects the llvmpipe GL adapter instead, and the Zed onboarding / project trust UI is visibly rendered. Both paths are software rendered. This is not a performance benchmark or a hardware acceleration test.

Expected: The default launch should show the editor, or fall back to an adapter that can actually present visible frames.

Zed version and system specs

• Zed: 1.26.2 stable, commit c4273271092b0287f7d181f616bd5171e0a2f70c
• OS: Debian GNU/Linux 12, x86_64, Linux 6.1
• Desktop: KDE/KWin, X11, Xorg dummy display
• Graphics: Mesa 22.3.6, LLVM 15.0.6, llvmpipe software Vulkan and software OpenGL
• X11 window: 32-bit depth

Relevant sanitized Zed logs

Default launch:

[gpui_wgpu::wgpu_context] Found 2 GPU adapter(s):
[gpui_wgpu::wgpu_context]   - llvmpipe (LLVM 15.0.6, 256 bits) (vendor=0x10005, device=0x0000, backend=Vulkan, type=Cpu)
[gpui_wgpu::wgpu_context]   - llvmpipe (LLVM 15.0.6, 256 bits) (vendor=0x10005, device=0x0000, backend=Gl, type=Cpu)
[gpui_wgpu::wgpu_context] Testing adapter: llvmpipe (LLVM 15.0.6, 256 bits) (Vulkan)...
[gpui_wgpu::wgpu_context] Selected GPU (passed configuration test): llvmpipe (LLVM 15.0.6, 256 bits) (Vulkan)
[gpui_wgpu::wgpu_context] Selected GPU adapter: "llvmpipe (LLVM 15.0.6, 256 bits)" (Vulkan)
[workspace] Rendered first frame

Control with Vulkan ICDs hidden:

[gpui_wgpu::wgpu_context] Found 1 GPU adapter(s):
[gpui_wgpu::wgpu_context]   - llvmpipe (LLVM 15.0.6, 256 bits) (vendor=0x10005, device=0x0000, backend=Gl, type=Cpu)
[gpui_wgpu::wgpu_context] Selected GPU adapter: "llvmpipe (LLVM 15.0.6, 256 bits)" (Gl)
[workspace] Rendered first frame

Code context and related reports

At v1.26.2, crates/gpui_wgpu/src/wgpu_context.rs enables both Vulkan and GL and prefers Vulkan over GL when the adapters otherwise have equal priority. A successful surface-configuration test does not establish that a frame was visible in this environment. The exact failure within the Vulkan/X11/Mesa presentation path is not yet identified.

Related historical reports: https://github.com/zed-industries/zed/issues/35009 and https://github.com/zed-industries/zed/issues/28418 involved similar transparent llvmpipe/X11 windows but earlier Zed versions/renderers. https://github.com/zed-industries/zed/issues/65960 concerns a different Wayland/VMware adapter-enumeration regression.

No screenshots or full logs are attached because they contain unrelated desktop content.