Summary
On an Ubuntu X11 guest in VMware Workstation, desktop input and app-menu search pause for seconds when a graphics client starts. Terminal commands and npm processing remain fast. Diagnostics reproduce the delay in Xorg's VMware DRI3 render-node opening path. Switching only the guest Xorg display driver to modesetting removes the measured stall while retaining SVGA3D hardware 3D acceleration.
Environment at diagnosis (30 September 2026)
- VMware Workstation 26.0.1, build 25688693; Windows host; VM hardware version 22.
- Ubuntu 24.04.5 LTS, kernel 7.0.0-34-generic, GNOME 46, X11 session.
- xserver-xorg-video-vmware 1:13.4.0-1build1.
- Mesa 25.2.8; libdrm 2.4.125; open-vm-tools and open-vm-tools-desktop 13.0.10.
- VMware SVGA II virtual GPU, kernel driver vmwgfx; direct rendering enabled, renderer SVGA3D.
- 8 vCPUs and approximately 36 GiB usable guest RAM.
- Host GPU NVIDIA RTX 5090 Laptop; original VKRenderer/Vulkan presentation enabled.
Steps to reproduce on the affected configuration
1. Use the guest's vmware Xorg display driver with 3D acceleration enabled.
2. Start a fresh graphics client from the graphical terminal, for example run glxinfo -B repeatedly and time each separate invocation.
3. Observe an approximately two-second wait per fresh graphics query. Starting app-menu search-provider applications also produces a visible desktop/input stall. Subsequent searches may be smooth because providers are already running.
4. Repeat after selecting the built-in modesetting driver as described below.
Expected result
Starting a graphics client should not synchronously freeze Xorg and desktop input for seconds.
Observed result and diagnostic evidence
- Untraced glxinfo -B invocations with the vmware Xorg driver took 2038.4, 1999.0 and 1996.8 ms.
- Client tracing showed 1.961848 seconds waiting for an Xorg response.
- An Xorg profile sampled the stack usleep -> libdrm -> drmOpenWithType -> vmware_drv.so.
- A targeted Xorg trace showed that the existing /dev/dri/renderD128 opens successfully. DRM_IOCTL_SET_VERSION and DRM_IOCTL_GET_UNIQUE return EACCES on that render node.
- The same initialization then probes nonexistent renderD129 through renderD191, with 50 retry/sleep calls per node: 3150 sleeps in total. Under tracing, cumulative sleep time was 2.075 seconds; tracing itself increases overall wall time.
- The render node already had user access. This is not an inability to open renderD128 due to its file permissions.
- An X11 responsiveness probe stalled for 1388.8 ms as the Nautilus search provider started.
Suspected faulty code path
In the released xf86-video-vmware 13.4.0 source, vmwgfx/vmwgfx_dri3.c constructs a PCI bus ID and calls:
fd = drmOpenWithType("vmwgfx", bus_id, DRM_NODE_RENDER);
The preceding source comment states that render nodes cannot be opened by bus ID yet. The observed delay occurs while this DRI3 opening path synchronously performs the libdrm render-node scan on Xorg's main thread. Please assess whether this should open the already identified render node directly or otherwise avoid bus-ID matching and missing-node retries.
Verified workaround
Create /etc/X11/xorg.conf.d/20-vmware-modesetting.conf in the guest:
Section "Device"
Identifier "VMware SVGA using modesetting"
Driver "modesetting"
Option "AccelMethod" "glamor"
EndSection
Save desktop work, restart the display manager and log in again. This closes desktop applications. The vmwgfx kernel driver and VMware 3D acceleration remain enabled; the vmware Xorg driver package can stay installed.
Validation after the workaround
- The same untraced queries took 50.0, 50.9 and 47.5 ms.
- Following a full VM power-off/start, queries took 58.1, 56.8 and 56.7 ms.
- Direct rendering remained enabled with SVGA3D. Xorg reported glamor acceleration enabled on SVGA3D.
- A subsequent concurrent 45-second sample had no failures: maximum X11 response 31.4 ms, maximum GNOME response 8.5 ms. These are service-response measurements, not FPS measurements.
- App-menu search and typing became smooth, confirmed repeatedly by the user.
Other isolation checks
Changing host presentation from Vulkan to DX12 did not remove the delay; that experiment was reverted. The final successful cold boot used the original Vulkan presentation. No power, Windows security or hypervisor settings were changed. No current CPU, memory, swapping or disk-wait bottleneck was observed. A generic Xorg DRI3-disable extension setting was ignored, so it was not the working fix.
Request to the VMware Desktop Hypervisor team
Please confirm whether this exact render-node probing stall has an existing internal bug ID. If not, please log it and route it to the responsible guest graphics / xf86-video-vmware maintainers, or advise the appropriate upstream reporting destination. A durable fix would avoid requiring users to replace the guest display driver manually. This report establishes the reproduced graphics-client startup stall; it does not claim to explain every unrelated historical GPU crash.