Nvidia proprietary (non-open) modules completely unable to acquire a DRM lease on any display server, all known nvidia drivers, any hardware

Attempting to use Monado or SteamVR on the older proprietary modules that are compatible with 10 series cards and lower looks to be entirely nonfunctional.

On X11 a lease can be attempted and the display connector appears ready for it but it fails for ‘unknown’ reasons:

Aug 04 22:42:22 msi monado-service[24533]:  INFO [comp_target_swapchain_override_extents] Target 'direct' overrides compositor extents with (2880x1600) was (0x0 false)
Aug 04 22:42:22 msi monado-service[24533]: DEBUG [compositor_try_window] Target backend direct initialized!
Aug 04 22:42:22 msi monado-service[24533]: DEBUG [comp_window_direct_nvidia_init_swapchain] Will use display: Valve Corporation Index HMD (DP-0)
Aug 04 22:42:22 msi monado-service[24533]: ERROR [comp_window_direct_acquire_xlib_display] vkAcquireXlibDisplayEXT: VK_ERROR_UNKNOWN (0x000055ee7152ad80)
Aug 04 22:42:22 msi monado-service[24533]: ERROR [compositor_init_swapchain] Window init_swapchain failed!
Aug 04 22:42:22 msi monado-service[24533]: ERROR [comp_main_create_system_compositor] Failed to init compositor 0x55ee71358dd0

Using XRT_COMPOSITOR_FORCE_VK_DISPLAY=1 to force a Vulkan display acquisition fails with completely bogus extents on both Wayland and X11 just the same.

Aug 04 22:50:11 msi monado-service[24715]:  INFO [comp_target_swapchain_override_extents] Target 'VkDisplayKHR' overrides compositor extents with (4226624525x4080412994) was (0x0 false)

Using XRT_COMPOSITOR_FORCE_WAYLAND_DIRECT=1 on the Monado service to force wayland direct display lease protocol for Monado results in the driver reporting no usable connectors at all

Aug 04 22:52:50 msi monado-service[25832]:  INFO [comp_window_direct_wayland_init] No connector was chosen, will use first available connector
Aug 04 22:52:50 msi monado-service[25832]:  INFO [_drm_lease_device_drm_fd] Available DRM lease device: /dev/dri/card1
Aug 04 22:52:50 msi monado-service[25832]:  INFO [comp_window_direct_wayland_init] Found no connectors available for direct mode
Aug 04 22:52:50 msi monado-service[25832]: ERROR [compositor_init_window_pre_vulkan] Failed to init Wayland Direct-Mode backend!
Aug 04 22:52:50 msi monado-service[25832]: ERROR [comp_main_create_system_compositor] Failed to init compositor 0x55a22f5fc040

It appears there’s a bug where any use of the older fully proprietary kernel module results in total failure to acquire any drm lease. This does not appear to be limited to any specific hardware as some other user testing has proven this reproducible on any card if the proprietary (not open) modules are installed.

Please be wary when reproducing there is a bug on the valve index headsets across all vendors and drivers where the headset must be power cycled to properly appear as a display but barring that, this bug persists here in these proprietary kernel modules and may be easily reproduced.

Simply pull Monado and test for yourself and note how everything on the proprietary kernel modules are affected.

If when testing wayland with XRT_COMPOSITOR_FORCE_WAYLAND_DIRECT and Monado reports no wayland_direct, ensure you do a fresh Monado cmake config with the system package wayland-protocols or wayland-protocols-dev/ wayland-protocols-devel installed as this is required by Monado’s build or it may silently fail to access the lease protocol and frustrate efforts to reproduce.

This may be reproduced anywhere from 555 to 580 to my knowledge, it affects a very wide range of driver versions even older than this I could see in a few very older user reports I will have to dig up.

I have verified that the laptop connector is directly wired to the Nvidia card in this laptop and is not influencing anything you see here. We have also verified that single GPU systems reproduce this behavior, failing to acquire a drm lease on the proprietary kernel modules. This appears to have been broken for some time, parsing very old user reports and was mostly buried by people adopting the open modules, which do work.

This must be some sort of a regression but I do not known how far back this runs, it appears to be quite deep and perhaps as old as the nvidia-open modules themselves now…

[bones@msi ~]$ nvidia-smi
Mon Aug  4 23:02:53 2025       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.65.06              Driver Version: 580.65.06      CUDA Version: 13.0     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce GTX 1070        Off |   00000000:01:00.0 Off |                  N/A |
| N/A   44C    P8              4W /  125W |       7MiB /   8192MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A           24868      G   /usr/lib/Xorg                             4MiB |
+-----------------------------------------------------------------------------------------+
[bones@msi ~]$ inxi
CPU: quad core Intel Core i7-7700HQ (-MT MCP-) speed/min/max: 900/800/3800 MHz
Kernel: 6.15.9-arch1-1 x86_64 Up: 1h 4m Mem: 2.13/11.57 GiB (18.4%)
Storage: 350.27 GiB (6.0% used) Procs: 243 Shell: Bash inxi: 3.3.38
1 Like

Addition for good measure:

Reproduced on a bigscreen beyond HMD and a valve index (after the necessary replug to get the display to appear correctly to the kernel).

2nd addendum:

I am absolutely certain the mobile hardware display routing is not the cause of any issue here as the USB-C is exposed to the Intel connectors and the miniDP is exposed to the Nvidia on my testing laptop here. Both of which exhibit the exact same behavior under all testing runs.

xrandr never presents the HMD as an display under X11 or under Xwayland.

The non-desktop properties here are not causing any issues as I am dealing with the separate issue of the Index presenting itself as a null EDID 640x480 assumed display on first plus (index issue) by replugging the headset shortly after to properly initialize it. Same results after this process.

The nvidia binary kernel module is unable to acquire any lease at all.

3rd addendum:

Verified forcing non-desktop on the connectors, despite xrandr reporting the HMD as disconnected, to non-desktop 1. Still not able to acquire a lease, same exact error matrix.

1 Like

A vive and a CV1 user have both confirmed working drm lease, meaning this issue is exclusive to the Valve Index headset.