SteamVR's compositor cannot acquire a DRM lease on the headset display and fails to start, with error VRInitError_Compositor_CannotDRMLeaseDisplay (often paired with the in-app "Can not connect to headset display" dialog, error 496). This happens on every SteamVR startup on this machine — 18/18 startups today, both idle and while launching a real game (VRChat) — even though every documented Linux VR requirement is met. This looks like an incompatibility between RTX 50-series (Blackwell) GPUs and SteamVR's Linux DRM-lease compositor path, not a local misconfiguration.
If you're on similar hardware (RTX 50-series GPU, Debian/Ubuntu-family Linux) and hitting the same wall, please add a 👍 / comment with your GPU model and driver version so Valve can see how widespread this is.
Environment
GPU
NVIDIA GeForce RTX 5060 Ti (Blackwell, PCI ID 10de:2d04)
NVIDIA driver
595.84 (proprietary)
OS
Linux Mint 22.3 (Zena) — Ubuntu 24.04/Debian-family
Launch SteamVR (steam steam://rungameid/250820) on the above hardware.
Observe the compositor fails to start almost immediately — no VR game needs to be running.
(Also reproduced identically while launching an actual VR title — VRChat, appid 438100 — so it isn't specific to SteamVR's idle/home state.)
Expected vs. actual
Expected: compositor acquires the display via DRM lease and SteamVR reaches its normal Home/dashboard state, ready to render.
Actual: compositor process starts, immediately fails to acquire an xlib/DRM display, and exits (~0.25s lifetime) with VRInitError_Compositor_CannotDRMLeaseDisplay.
Log evidence
From vrcompositor.txt (timestamps from a run captured today; identical sequence recurs on every startup):
Sun Aug 02 2026 22:46:07.608014 [Info] - Selected mode 8.
Sun Aug 02 2026 22:46:07.673351 [Info] - Failed to acquire xlib display
Sun Aug 02 2026 22:46:07.673401 [Error] - CHmdWindowSDL: Failed to create direct mode surface
Sun Aug 02 2026 22:46:07.673470 [Error] - CHmdWindowSDL: VR requires direct mode.
Sun Aug 02 2026 22:46:07.673573 [Error] - Error making window!
Sun Aug 02 2026 22:46:07.710488 [Info] - Failed to kill gpu-trace
Sun Aug 02 2026 22:46:07.710609 [Info] - Failed to initialize compositor
Sun Aug 02 2026 22:46:07.710641 [Info] - Failed to start compositor: VRInitError_Compositor_CannotDRMLeaseDisplay
Corresponding vrmonitor.txt entries show the compositor process connecting and disconnecting within ~0.29 seconds of being launched:
Sun Aug 02 2026 22:46:07.421063 [Info] - New Connect message from .../vrcompositor (VRApplication_Background) ... 295112
Sun Aug 02 2026 22:46:07.711676 [Info] - Process 295112: vrcompositor disconnected
Tested directly against the live compositor log — both produced the identical failure, so these are not the cause:
SteamVR's global direct_mode.enable setting set to false.
Removing Prop_DisplayDebugMode_Bool from the HMD driver's Activate() (tested with it matching Valve's own simplehmd sample).
Notes for others posting a similar report
Double-check nvidia-drm.modeset=1 via both/proc/cmdlineand/etc/modprobe.d/*.conf — on Debian/Ubuntu-family distros the NVIDIA package sets it via a modprobe config file, not the kernel cmdline, so checking only the cmdline gives a false negative.
Worth including in your own report: GPU model + exact driver version, whether Steam is native/.deb vs Flatpak/Snap, X11 vs Wayland session, and the exact VRInitError_* code from your own vrcompositor.txt.
Summary
SteamVR's compositor cannot acquire a DRM lease on the headset display and fails to start, with error
VRInitError_Compositor_CannotDRMLeaseDisplay(often paired with the in-app "Can not connect to headset display" dialog, error 496). This happens on every SteamVR startup on this machine — 18/18 startups today, both idle and while launching a real game (VRChat) — even though every documented Linux VR requirement is met. This looks like an incompatibility between RTX 50-series (Blackwell) GPUs and SteamVR's Linux DRM-lease compositor path, not a local misconfiguration.If you're on similar hardware (RTX 50-series GPU, Debian/Ubuntu-family Linux) and hitting the same wall, please add a 👍 / comment with your GPU model and driver version so Valve can see how widespread this is.
Environment
10de:2d04).debpackage (not Snap/Flatpak)nvidia-drm.modeset=1/etc/modprobe.d/nvidia-graphics-drivers-kms.conf)/dev/drivideo/rendergroup permissions, no other process holding itAll of the above matches Valve's documented SteamVR-for-Linux requirements.
Steps to reproduce
steam steam://rungameid/250820) on the above hardware.Expected vs. actual
VRInitError_Compositor_CannotDRMLeaseDisplay.Log evidence
From
vrcompositor.txt(timestamps from a run captured today; identical sequence recurs on every startup):Corresponding
vrmonitor.txtentries show the compositor process connecting and disconnecting within ~0.29 seconds of being launched:Reproduction count today, by timestamp of
VRInitError_Compositor_CannotDRMLeaseDisplayinvrcompositor.txt: 02:05, 02:31, 02:40, 02:49 (×2), 02:50, 03:02, 03:04, 03:08, 22:38, 22:39 (×3), 22:42 (×2), 22:44, 22:45, 22:46 — 18 consecutive failures, 0 successes.Things already ruled out
Tested directly against the live compositor log — both produced the identical failure, so these are not the cause:
direct_mode.enablesetting set tofalse.Prop_DisplayDebugMode_Boolfrom the HMD driver'sActivate()(tested with it matching Valve's ownsimplehmdsample).Notes for others posting a similar report
nvidia-drm.modeset=1via both/proc/cmdlineand/etc/modprobe.d/*.conf— on Debian/Ubuntu-family distros the NVIDIA package sets it via a modprobe config file, not the kernel cmdline, so checking only the cmdline gives a false negative.VRInitError_*code from your ownvrcompositor.txt.