[BUG] [Linux] Headless SteamVR 2.16.3 + UE 5.7: OpenXR Session Failure with Null Driver on Kubuntu 24.04

[rbeattieevertz]

System Information:

OS: Kubuntu 24.04 (LTS)
SteamVR Version: 2.16.3 (1776109782)
Hardware: Vive Trackers (2.0) + Watchman Dongles
Engine: Unreal Engine 5.7 (OpenXR)

Issue Description:

I am attempting to run a headless SteamVR session to ingest Vive Tracker data into Unreal Engine 5.7 via LiveLinkXR. While the null driver loads, SteamVR refuses to activate the HMD "Universe," leading to an XR_ERROR_RUNTIME_FAILURE when Unreal attempts to create an OpenXR session.

Steps to Reproduce:

Configure steamvr.vrsettings with "forcedHmd": "null" and "requireHmd": false.
Enable driver_null in the driver resources.
Launch SteamVR.
Launch Unreal Engine 5.7 with the -xrtrackingonly flag.

Actual Behavior:

Log Error (SteamVR): Can't add device null.Null Serial Number: Does not match user setting "forcedHmd".

Standby Issue: Even when the HMD is forced, the system logs entering standby after ~10 seconds, effectively killing the tracking stream.

OpenXR Failure: Unreal Engine fails at xrCreateSession because the SteamVR compositor cannot lease a display in a headless environment, even when tracking-only is requested.

Expected Behavior:

SteamVR should initialize a virtual coordinate system (Universe) using the Null HMD and maintain an "Active" state (not standby) so that OpenXR applications can pull tracker poses without a physical display attached.

steamvr.txt
vrserver.txt

[Packetdancer]

Minor correction -- "forcedHmd" should be set to the serial number of the HMD you want to force it to use.

(I know you did this correctly -- I can see that it's "Null_0001" in the actual config file and logs -- but I'm adding this for the sake of repro clarity.)

[Packetdancer]

Somewhat disconcertingly, I cannot reproduce this off of a live build from main -- with a null HMD and two Knuckles controllers being tracked, I get a universe just fine, and the XR session state is what I would expect.

Before I dive in too much further, can I ask you to check one thing? Specifically, I'm pretty sure we're bundling the helloxr_vulkan test binary in SteamVR, so if you start things up in the configuration you're using, instead of running Unreal, can you:

cd ~/.steam/steam/steamapps/common/SteamVR/bin/linux64
../vrenv.sh ./helloxr_vulkan -t Vulkan -ff Hmd

...and see what happens?

Because I see a universe in the logs for my environment and not yours, I suspect that helloxr will also tank on you, in which case I will continue to dig further. But if it does not -- if it properly starts up and you see an XR session transition all the way to SYNCHRONIZED in the text spew -- then that'll mean the issue's probably related to something in Unreal's XR handling, and I have a different place to start looking.

[rbeattieevertz]

Thanks for the response. The output from the command is shown below. Universe 1777457962 is being successfully created and the trackers are seen, but the compositor is crashing with the CannotDRMLeaseDisplay error.

Before:

vrcompositor.txt
vrserver.txt

After:

vrcompositor.txt
vrserver.txt

I ran through the process on Windows and it works OK. The main difference is Windows a display Window pops up instead of the headset and I can complete the SteamRoom VR setup (Standing only). I assume it's not able to create the virtual display. The Vulkan 386 drivers are installed (sudo apt install libnvidia-gl-580:i386). I also had to set the SteamVR runtime manually. I have included my config files.

~/.steam/debian-installation/steamapps/common/SteamVR/drivers/null/resources/settings/default.vrsettings
~/.steam/steam/steamapps/common/SteamVR/resources/settings/default.vrsettings

default.vrsettings_1.txt
default.vrsettings_2.txt

rob@newpc:~/.steam/steam/steamapps/common/SteamVR/bin/linux64$ ../vrenv.sh ./helloxr_vulkan -g Vulkan -ff Hmd
vrenv.sh[9924]: VRCOMPOSITOR_LD_LIBRARY_PATH=/home/rob/.steam/steam/steamapps/common/SteamVR/bin/linux64:/home/rob/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/qt/lib:/home/rob/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64
vrenv.sh[9924]: exec ./helloxr_vulkan -g Vulkan -ff Hmd
[12:09:26.371][Info ] Press any key to shutdown...

[12:09:26.377][Info ] Available Layers: (0)
[12:09:26.389][Info ] Instance RuntimeName=SteamVR/OpenXR RuntimeVersion=2.15.6
[12:09:26.389][Info ] Available View Configuration Types: (1)
[12:09:26.389][Info ] Available Environment Blend Mode count : (1)
[12:09:26.389][Info ] Environment Blend Mode (XR_ENVIRONMENT_BLEND_MODE_OPAQUE) : (Selected)
[12:09:26.690][Info ] Loaded vertex shader
[12:09:26.691][Info ] Loaded fragment shader
vrcompositor-launcher.sh[9945]: Relaunch under scout LDLP runtime.
vrcompositor-launcher.sh[9945]: exec /home/rob/.steam/root/ubuntu12_32/steam-runtime/run.sh /home/rob/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor-launcher.sh
vrcompositor-launcher.sh[9945]: Detected scout LDLP runtime.
vrcompositor-launcher.sh[9945]: exec /home/rob/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor-launcher
Using vrcompositor capability proxy
Launching /home/rob/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrcompositor
Using breakpad crash handler
Setting breakpad minidump AppID = 250820
Forcing breakpad minidump interfaces to load
Looking up breakpad interfaces from steamclient
Calling BreakpadMiniDumpSystemInit
04/29 12:09:26 minidumps folder is set to /tmp/dumps
04/29 12:09:26 Init: Installing breakpad exception handler for appid(250820)/version(2.15.6)/tid(9945)
[12:09:27.283][Error ] XrResult failure [XR_ERROR_RUNTIME_FAILURE]
Origin: xrCreateSession(m_instance, &createInfo, &m_session)
Source: /data/src/thirdparty/openxr_public/src/tests/hello_xr/openxr_program.cpp:581

[Packetdancer]

Thanks, that's helpful data.

[Packetdancer]

Just on a whim -- what happens if you add windowWidth and windowHeight to the null driver settings, with 3840 and 2160 respectively? I don't necessarily expect this will work, but I do suspect it'll probably at least do something different.

At a quick glance, the issue looks to be that the system is trying to find a display to create a Vulkan surface tied to that device (even if there's no actual visible output), and it is trying to find the HMD display by matching width/height as a fallback when it cannot otherwise find one...

(On Windows, this works differently, which is why you don't run into the problem there.)

If that doesn't work, I suspect that explicitly setting enableLinuxVulkanAsync to false in the steamvr section of settings probably will.

This is absolutely something that we should change in terms of working properly with the null HMD -- at the very least we should surface a better error -- but I am curious what will happen in the meantime if you try these settings.

[rbeattieevertz]

I followed your suggestion and updated the null driver's windowWidth and windowHeight to 3840 and 2160. The vrcompositor log now shows a successful match: Mode 0 0x222 3840x2160 (looking for 3840x2160). However, it still fails after with VRInitError_Compositor_CannotDRMLeaseDisplay. (PS I had actually tried that one already)

vrcompositor.txt
vrserver.txt

default.txt