[BUG] [Linux] Steam Link VR NVIDIA startup crash in `videovulkan::SetupEncoder()` quality-level query

steamvropen bugFixed in Main

ValveSoftware/SteamVR-for-Linux#898 · opened 2026-05-23 by 46cv8 · updated 2026-08-17 · 14 comments · github

446cv8 2026-05-23 github

Describe the Bug

When connecting a Meta Quest 2 through Steam Link VR on Linux, SteamVR begins
initializing Valve's vrlink Vulkan video encoder, then vrserver segfaults
and the headset disconnects. The desktop displays:

SteamVR Graphics Error
You may need to update your computers graphics
(405)

I traced the crash in Valve's unmodified driver_vrlink.so to an indirect call
from videovulkan::SetupEncoder() through
vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR. In the failing run,
that call dispatches through a null pointer.

A one-branch diagnostic bypass of the NVIDIA quality-level query path lets the
same system initialize Steam Link VR and reach SteamVR Home, including with
10-bit video enabled.

To Reproduce

Use Valve's unmodified SteamVR driver_vrlink.so.
Start SteamVR on the Linux host.
Start Steam Link VR on the Quest 2 and connect to the host.
Wait for headset/encoder initialization.

Expected Behavior

Steam Link VR should connect and enter SteamVR Home or another VR scene.

Actual Behavior

SteamVR displays error (405), the headset session disconnects, and vrserver
segfaults during driver_vrlink.so video encoder setup.

System Information

Distribution: Ubuntu 22.04.5 LTS
Kernel: 6.8.0-111-generic ([#111](/issue/ValveSoftware/SteamVR-for-Linux/111)~22.04.1-Ubuntu)
GPU: NVIDIA GeForce RTX 3060
NVIDIA driver: 595.71.05
SteamVR version: 2.15.6
SteamVR beta also tested: build shown by Steam as 23084509; same startup failure
Steam client version: [fill in from Steam > Help > About Steam before submitting]
Headset/client: Meta Quest 2, Steam Link VR (qvlclient;hollywood;2.0.22.2080)
Connection type: wireless Steam Link VR
Vulkan encode extensions reported by vulkaninfo:

VK_KHR_video_encode_h264
VK_KHR_video_encode_h265
VK_KHR_video_encode_intra_refresh
VK_KHR_video_encode_quantization_map
VK_KHR_video_encode_queue

Log Sequence Immediately Before the Crash

driver_vrlink.txt from the unmodified-driver run ends its encoder
initialization sequence with:

SVLRoot::SVLRoot() sReqEncMode = mid
SVLDataLink::InitCrypt() m_TransportMode = 1 // 1017
[HMDVulkan] Created VkDevice with Compute Queue Family: 2 and Video Encode Queue Family: 4.
[VideoVulkan] Init()
[VideoVulkan] Is 10 bit SUPPORTED? Yes
[VideoVulkan] Is Ultra Low Latency SUPPORTED? Yes
m_eChosenRateControlMode: 4
[VideoVulkan] Setting video capabilties: 10bit: No, ull: Yes

The resulting primary crash is:

CrashID=bp-be86bd8c-687a-4084-8043-606bd2260523
vrserver[53368]: segfault at 0 ip 0000000000000000
Exception=EXCEPTION_SIGSEGV
Module=driver_vrlink.so
Symbol=videovulkan::SetupEncoder()
Return address=driver_vrlink.so+0xba1b9

Disassembly at the Crash Site

The unmodified SteamVR 2.15.6 binary contains the following instruction
sequence at the failing call:

ba14f: lea    0xc7c6a2(%rip),%rax # d367f8 <vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR>
ba1b0: mov    0x8(%rdx),%rdi
ba1b4: mov    %r8,%rdx
ba1b7: call   *(%rax)
ba1b9: test   %eax,%eax

The crash instruction pointer is 0x0, indicating that
call *(%rax) attempted to invoke a null
vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR pointer.

I also repeated the startup test with Steam's Fossilize layer disabled. It
failed at the same driver_vrlink.so+0xba1b9 return address, so Fossilize is
not the cause of this initialization failure.

Diagnostic Binary Diff

I only have the shipped binary, not VRLink source. The following one-branch
binary change was used only to test whether the quality-level path is the
blocking failure:

 File offset:      0x000b9ba2
 Original SHA256:  1191bb8f8f63e5572888ee0dab5f4586b6394189ce5a26ee508521fd1875ea86

-0f 84 68 05 00 00    je videovulkan::SetupEncoder()+0x670   ; enter NVIDIA quality-level query path
+90 90 90 90 90 90    nop; nop; nop; nop; nop; nop            ; continue through normal video-session path

 Patched SHA256:   b3aaf53e91c6d6a1d2a714d72c88df61d89bd14b4f07c3c0fd4d572ea815c177

Result After the Diagnostic Bypass

With only that branch bypass applied, Steam Link VR passes its prior startup
crash and initializes successfully:

[VideoVulkan] Created vkCreateVideoSessionKHR! chosen m_MaxSVLVideoExtent: 3200x8192
[VideoVulkan] Init Success!
[HMDVulkan] Activate: Done!

I could then reach SteamVR Home on the Quest 2. With the SteamVR setting below,
10-bit initialization also succeeded:

"driver_vrlink": {
  "10bit": true
}

[VideoVulkan] Is 10 bit SUPPORTED? Yes
[VideoVulkan]    format: 1000156013
[VideoVulkan] Init Success!
[HMDVulkan] Activate: Done!

Suggested Code-Level Fix

driver_vrlink should verify that
vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR has been loaded
before calling it. If the function is unavailable, setup appears capable of
continuing using its non-quality-level/default selection path.

Conceptually:

-result = vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR(physical_device, &query, &properties);
-if (result == VK_SUCCESS) {
-    apply_quality_level_properties(properties);
-}
+if (vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR != nullptr) {
+    result = vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR(physical_device, &query, &properties);
+    if (result == VK_SUCCESS) {
+        apply_quality_level_properties(properties);
+    }
+} else {
+    use_default_encode_configuration();
+}

The actual source structure may differ; the important observable behavior is
that the quality-level query is entered with an invalid function pointer and
skipping that query allows encoder initialization to complete.

Related Public Tracker Context

ValveSoftware/SteamVR-for-Linux#837 reported a broad Steam Link connection
crash on Quest hardware and was closed on 2026-03-27 after its original
reporter stated that it no longer reproduced. It may be related by symptom,
but it does not identify this videovulkan::SetupEncoder() call site.
I could not find public VRLink implementation source in
ValveSoftware/SteamVR-for-Linux; the repository currently contains issue
templates and diagnostics/documentation files rather than
driver_vrlink.so source.

Attachments Available

The unmodified-driver vrserver minidump associated with the CrashID above
driver_vrlink.txt and vrserver.txt from the unmodified failing run
driver_vrlink.txt and vrserver.txt from the successful diagnostic-bypass run
Steam runtime diagnostics and SteamVR system report: [generate immediately before submitting]

Separate Follow-Up Observation

After the diagnostic bypass allowed SteamVR Home to run, launching a VR
application exposed a separate crash during SteamVR Home texture teardown in
SVLHMDDriverVulkan::GetTextureSize() from the submit thread. I am not
treating that as this issue's primary bug because it was observed only after
applying the diagnostic bypass and is distinct from the reproducible
unmodified-driver startup failure described above.

Forgive me for having the AI write this bug report but I'm sure your AI can fix the code if it listens to my AI ;)

PPacketdancer 2026-05-30 github

There have been some reports of weird behavior with the Nvidia 595 proprietary driver, so it would be useful to test with version 580 just for comparison's sake.

In addition, you say 'attachments available' but did not include the attachments. Those logfiles would be useful, as driver_vrlink.txt in particular includes quite a bit about the overall initialization, and will make it more obvious if anything's going wrong. (Albeit only in the beta builds, so it would be best to generate the logs with the 2.16.5 beta.)

Also, fwiw, the AI summary isn't useful; it just sort of makes the bug overly verbose without necessarily adding much.

446cv8 2026-05-30 github

I think the part about "vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR" is pretty clear, I ran into other issues with steamlink crashing later on due to what turned out to be network issues but before I figured that out I had already switched to ALVR in the end. I'll try to dig up the driver_vrlink.txt files. Also I think it was crashing with 580 drivers for a different reason something related to some codec initialization errors (I don't have the logs for that). That was resolved by updating to the nvidia 595 drivers.

original_driver_vrlink.txt
patched_driver_vrlink.txt

Unfortunately right now I can't reinstall steamvr beta drivers and I also can't downgrade my nvidia drivers. If the data as is in this ticket isn't actionable, just close it.

PPacketdancer 2026-05-31 github

To elaborate a bit here, while I can certainly add a guard there, the function is called in a place where it not being present is worrisome; simply checking for the existence of the function may fix this particular immediate crash, but I suspect it conceals a deeper problem with this Nvidia driver (and I worry that blindly charging on without finding that will just lead to some weirder issue down the road).

Unfortunately, I cannot reproduce this crash. I have, however, seen one other report in the wild of someone with a similar crash under 595 that went away on reverting to 580... thus my question if it goes away for you if you use 580, or if we could get a log for 595 under SteamVR 2.16.5 (which logs considerably more information on vrcompositor starting).

If I can confirm that it's 595, or get more detailed logging of all the Vulkan initialization, it's more likely to produce a better long-term fix. :)

446cv8 2026-07-04 github

I reproduced this again on an unmodified SteamVR beta driver before re-applying my local workaround. Attached is a redacted log bundle from SteamVR beta 2.17.3 with NVIDIA 595.71.05.

The relevant crash upload ID is:
bp-c241afb3-7316-493c-bf4b-85fdf2260703

I attached a small redacted bundle. The main file is driver_vrlink.txt, but I also included vrserver.txt, the crash upload excerpt, Steam Link connection lines, and the kernel segfault line in case they help correlate the failure.

steamvr_issue_898_beta_unmodified_failure_redacted_20260704.zip

PPacketdancer 2026-07-06 github

In theory this feature is only being used if a) Nvidia (because AMD's defaults work better than manually-requested quality), and b) the driver reports support for the feature, so it still kinda feels like a driver regression to me; the driver ought not to report support for the quality extensions if it does not provide them.

Even more irritatingly, I cannot reproduce it on Nvidia 595 drivers; for me, the function is in fact implemented and non-null, on my dev box and on the test rig in the other room.

I would still really like to know what the underlying cause here is, and so I am still curious whether it would happen for you with version 580 of the Nvidia drivers. Since I cannot reproduce it, I cannot test whether it's a change in 595 that breaks it, but the only other report I've seen of a crash like this was someone who had it happen under 595 but not under 580.

Still, at this point, I'll just add an extra guard.

446cv8 2026-07-06 github

If it's working for you on 595, then it may just be my system has some inconsistent driver state or something. I'll see if I can find any leads that indicate that is the case. I'll update here in another day after I have a chance to look.

446cv8 2026-07-07 github

Ok so I don't know if this is helpful or not but this is as far as I can go currently.

I ran an additional standalone Vulkan proc-address probe to avoid guessing about whether the NVIDIA ICD actually exposes this function.

On this system, the NVIDIA physical device reports the relevant video encode extensions, including VK_KHR_video_encode_queue and VK_KHR_video_encode_quantization_map.

The probe found that vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR is available when resolved with:

vkGetInstanceProcAddr(valid_instance, "vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR")

but it returns NULL when resolved with:

dlsym(libvulkan, "vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR")
vkGetInstanceProcAddr(NULL, "vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR")
vkGetDeviceProcAddr(valid_device, "vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR")

For comparison, device-level video commands such as vkCreateVideoSessionKHR and vkCmdEncodeVideoKHR do return non-NULL from vkGetDeviceProcAddr() after creating a device with the video extensions enabled.

So I do not think this proves the NVIDIA ICD globally lacks the function. It shows that the function pointer is lookup-context-dependent on my system. The original SteamVR crash still appears to be a NULL call through the driver_vrlink function-table slot for vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR, but I cannot say from outside the binary which lookup path populated that slot.

I also confirmed the active NVIDIA Vulkan stack appears coherent: RTX 3060, driver/package/ICD library all at 595.71.05; I did not find evidence of a mixed active 580/595 Vulkan stack in these checks.

PPacketdancer 2026-07-07 github

Hm. Well, it's resolving with vkGetInstanceProcAddr using the instance, not null. (Both in the code, and when I run it in a debugger.) So it's the path that should return non-null on your machine (and does on mine). At this point, I dunno...

Like I said, I went ahead and added the extra guard in main, though. So it should propagate to an upcoming beta. Hopefully that helps, at least!

446cv8 2026-07-08 github

Thanks a bunch! Sorry I couldn't track down the exact cause for you with more detail. I'll let you know if the beta starts working for me without the patching in afew weeks or so!

PPacketdancer 2026-07-10 github

One thing that actually has occurred to me -- if you run the unpatched version outside of the pressure vessel, does it still end up with a nullptr?

To do so, make sure SteamVR isn't running (and isn't patched, obviously) and then:

cd ~/.steam/steam/steamapps/common/SteamVR/bin/linux64
../vrenv.sh ./vrmonitor

If that works without the patch, then it means something in how SteamVR is running inside of a specific Steam pressure-vessel runtime on your machine is causing the issue. (In which case, I'd be curious if there's a compatibility tool override set on SteamVR in your library.)

FFmstrat 2026-08-14 github

Will this fix be making it's way into SteamVR? I'm running Ubuntu 26.04 and attempting to connect a Quest 2 via Steam Link and am running into this same issue (nvidia-driver-580).

446cv8 2026-08-14 github

Sorry I haven't had a chance o test your above mentioned suggestion yet about running outside the pressure vessel as I don't have the quest headset currently. @Fmstrat I don't know if it would be useful from @Packetdancer if you ran the test she mentioned above or not.

Eemiliopedrollo 2026-08-16 github

Same error dialog as this issue, but the failure happens earlier than the crash discussed here, so I don't think the SetupEncoder() guard in main will cover it — reporting it here since @Fmstrat hit this on 580 too.

There is no segfault and SetupEncoder() is never reached. vkCreateDevice itself fails:

[HMDVulkan] 3 physical devices available
[HMDVulkan] Found 1 candidate devices
[HMDVulkan] Checking device 'NVIDIA GeForce GTX 1070' with driver 'NVIDIA'
[HMDVulkan] Using device 'NVIDIA GeForce GTX 1070' with driver 'NVIDIA'
[HMDVulkan] VRSystem adapter LUID set to 0x58683f73f32ba7c8
[HMDVulkan] Got VkInstance + VkPhysicalDevice
[HMDVulkan] Found regular graphics queue!
[HMDVulkan] Failed to create device: -7
[HMDVulkan] Failed to create device... Exiting...
[HMDVulkan] Deactivate()

-7 is VK_ERROR_EXTENSION_NOT_PRESENT. Note the contrast with the working log posted earlier in this issue, which reaches
Created VkDevice with Compute Queue Family: 2 and Video Encode Queue Family: 4. — here only the graphics queue is logged before the failure.

Everything up to that point works: the headset is detected and connected (Autodetected Oculus Quest 2, DeviceType oculus/VRLINKHMDQUEST2, Connection active). The headset then shows "Host not responding" and the desktop shows the Graphics Error / "update your graphics driver" dialog.

System Information

Distribution: Ubuntu 24.04.4 LTS, kernel 6.8.0-137-generic
GPU: NVIDIA GeForce GTX 1070 (GP104, PCI ID 0x1B81) — Pascal
NVIDIA driver: 580.173.02 (Vulkan apiVersion 1.4.312)
SteamVR: beta 2.17.7, BuildID 24623212
Headset/client: Meta Quest 2, Steam Link VR (qvlclient;hollywood;2.0.22.2145)
Connection: wireless
Session: GNOME/Wayland (no DRM-leasing errors in vrcompositor.txt with VRLink)

Which extensions are missing

The device does expose video encode: VK_KHR_video_encode_queue, VK_KHR_video_encode_h264, VK_KHR_video_encode_h265, VK_KHR_video_encode_quantization_map, plus a queue family with QUEUE_VIDEO_ENCODE_BIT_KHR.

Diffing the VK_* strings in driver_vrlink.so against the device extensions reported by vulkaninfo for this GPU, the device-level ones it references but does not have are:

VK_VALVE_video_encode_rgb_conversion
VK_KHR_maintenance9

It also lacks VK_KHR_video_encode_intra_refresh, which appears in the extension list posted by the original reporter.

VK_VALVE_video_encode_rgb_conversion was only added in Vulkan 1.4.327; this driver implements 1.4.312, so it cannot expose it.

Why "update your graphics driver" is not actionable here

Earlier in this thread, updating 580 → 595 is what fixed the "codec initialization errors" on 580. That upgrade path does not exist for Pascal. From the Ubuntu package modaliases:

Package	First supported device ID	GP104 (`1B81`)
`nvidia-driver-580`	`1340` (Maxwell/Pascal)	present
`nvidia-driver-595`	`1E02` (Turing)	absent
`nvidia-driver-610`	`1E02` (Turing)	absent

580 is the last branch that supports this GPU, and it is the branch that fails. ubuntu-drivers devices correspondingly offers only 580/565/390 for it.

Question

Is Pascal in scope for VRLink? If the encoder requires extensions that only exist in driver branches which dropped Pascal, then for these GPUs the failure is permanent, and a specific message ("GPU/driver does not support the required video encode extensions") would be more useful than the current suggestion to update the driver, which cannot succeed.

If it is in scope, is a fallback path without VK_VALVE_video_encode_rgb_conversion feasible?

Happy to run the outside-the-pressure-vessel test from your earlier comment, or grab any additional logging, if useful.

FFmstrat 2026-08-17 github

Sorry I haven't had a chance o test your above mentioned suggestion yet about running outside the pressure vessel as I don't have the quest headset currently. @Fmstrat I don't know if it would be useful from @Packetdancer if you ran the test she mentioned above or not.

I tried the above test, and I still get the crash.

Nothing extracted yet.