WSLg fails to detect both Intel iGPU and NVIDIA RTX 5060 on Lenovo Yoga Pro 16 (2025)

[mrunbengable2233-lgtm]

### Windows build number:

10.0.26200.0

Your Distribution version:

24.04

Your WSL versions:2.6.1.0

Description
WSLg fails to detect and utilize both the integrated Intel GPU and discrete NVIDIA RTX 5060 on my Lenovo Yoga Pro 16 (2025). Mesa always falls back to llvmpipe, and all GPU-accelerated applications (Chrome, VLC, Zutty) crash unless GPU acceleration is explicitly disabled. This issue is more severe than #1394, which only affects Intel iGPU. In my case, neither GPU is usable, despite /dev/dxg and d3d12_dri.so being present.

System Info

• Device: Lenovo Yoga Pro 16 (2025)
• CPU: Intel Ultra 9 285H
• iGPU: Intel Xe (Ultra graphics)
• dGPU: NVIDIA RTX 5060
• WSL Version: 2.6.1.0
• Kernel Version: 6.6.87.2-1
• WSLg Version: 1.0.66
• MSRDC Version: 1.2.6353
• Direct3D Version: 1.611.1-81528511
• DXCore Version: 10.0.26100.1-240331-1435.ge-release
• Windows Version: 10.0.26200.7171
• Distro: Ubuntu 24.04
• Mesa: Includes d3d12_dri.so

Symptoms

• Mesa always reports llvmpipe as renderer:
  glxinfo | grep "OpenGL renderer"
  vulkaninfo | grep deviceName
• /dev/dxg exists, but dmesg shows repeated ioctl failures:
  dxgkio_query_adapter_info: Ioctl failed: -22
• Chrome, VLC, Zutty crash unless GPU acceleration is disabled.
• Windows always shows "HDR display ready" when switching to dGPU; brightness control logic is unstable.
• No way to force WSLg to use dGPU; environment variable MESA_D3D12_DEFAULT_ADAPTER=1 has no effect.

What I’ve Tried

• Verified /dev/dxg exists
• Verified d3d12_dri.so is present
• Tried setting MESA_D3D12_DEFAULT_ADAPTER=0/1
• Tried disabling HDR in Windows
• Tried forcing WSL to use dGPU via Windows graphics settings
• Tried Studio vs Game Ready drivers
• Tried older Intel DCH drivers (WDDM 3.0)

Additional Notes

• This machine has no hardware MUX, only software GPU switching.
• This machine supports Advanced Optimus, but WSLg still fails to detect the discrete GPU.
• In Windows, switching to dGPU causes brightness/HDR issues, and WSLg still fails to detect GPU.
• This issue seems to be a combination of:
• WSLg DXG bridge failing to enumerate adapters
• Intel DCH driver regression
• NVIDIA DXG virtualization failure
• Lenovo BIOS/software GPU switching logic interfering with DXG

Logs
dmesg | grep dxg
[ 0.766930] hv_vmbus: registering driver dxgkrnl
[ 4.810371] misc dxg: dxgk: dxgkio_is_feature_enabled: Ioctl failed: -22
[ 4.810371] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22
(repeated)

Suggested Priority
High – This issue blocks all GPU-accelerated GUI applications in WSLg, even with fallback attempts. It affects both Intel and NVIDIA

Steps to reproduce:

No

WSL logs:

WslLogs-2025-12-01_18-47-35.zip

WSL dumps:

No response

Expected behavior:

No response

Actual behavior:

• WSLg fails to detect both Intel iGPU and NVIDIA RTX 5060.
• Mesa always falls back to llvmpipe as renderer.
• /dev/dxg exists, but repeated ioctl failures occur:
  dxgkio_query_adapter_info: Ioctl failed: -22
• GPU-accelerated applications (Chrome, VLC, Zutty) crash unless GPU acceleration is disabled.
• Forcing WSL to use dGPU via Windows graphics settings or MESA_D3D12_DEFAULT_ADAPTER=1 has no effect.
• Windows shows “HDR display ready” when switching to dGPU, brightness control logic becomes unstable.
• No way to bypass iGPU and directly use dGPU in WSLg.

##Follow-up: Host GPU virtualization is incomplete

After further investigation, I’ve confirmed that the root cause is not in WSLg itself, but in the Windows host GPU virtualization layer.
Running Get-VMHostPartitionableGpu returns a valid device path for the RTX 5060, but all resource values (VRAM, Encode, Compute) are either placeholder values or unrealistically low. This suggests that Windows failed to properly initialize GPU-P (GPU Partitioning) for the discrete GPU.
Additionally:

• Get-VMGpuPartitionAdapter requires a VM name and returns no bindings, indicating no active GPU-P usage.
• Reset-VMGpuPartitionAdapter is not recognized, likely due to missing Hyper-V modules or unsupported SKU.
• In dGPU-direct mode, Windows correctly shows the built-in panel’s EDID name (starting with “AN TA…”), confirming that Advanced Optimus is functioning and the panel is physically routed to the dGPU.
• However, WSLg still fails to enumerate the dGPU and falls back to llvmpipe, even in this direct mode.
  This confirms that DXG ioctl failures (-22) are caused by incomplete GPU virtualization on the host side, not by WSLg itself.