[BUG] vrserver SIGSEGV in VRLink Vulkan video initialization when PICO 4 Enterprise connects (Linux, NVIDIA RTX 5060)

Start with the SteamVR 2.17.6 build 23791826 coredump and the reported driver_vrlink.so + 0x1033fc frame, alongside the VideoVulkan log immediately before the crash. Symbolicate that frame and inspect the return values or pointers used after 10-bit, ultra-low-latency, and rate-control mode 4 selection. Done means identifying the failing operation or confirming what additional private logs or coredump data are required.

Suggested title

[BUG] vrserver SIGSEGV in VRLink Vulkan video initialization when PICO 4 Enterprise connects (Linux, NVIDIA RTX 5060)

Describe the bug

On Linux, SteamVR starts normally and Steam Link establishes a connection with a PICO 4 Enterprise. The headset and both controllers are detected successfully. As soon as VRLink initializes Vulkan video encoding, vrserver terminates with SIGSEGV.

The crash is deterministic and has been reproduced three times. It occurs on both SteamVR 2.16.7 stable and SteamVR 2.17.6 beta. The 2.17.6 test was performed after opting into the current SteamVR beta as requested by the issue template.

The coredump consistently starts in Steam Runtime's libvulkan.so.1.3.239, called directly from driver_vrlink.so, followed by vrserver.

To reproduce

1. Start Steam and SteamVR on the Linux host.
2. Start Steam Link on a PICO 4 Enterprise on the same LAN.
3. Connect the headset to the host.
4. Wait for VRLink to discover the headset and controllers.
5. vrserver crashes immediately during [VideoVulkan] Init().

Expected behavior

VRLink should initialize the video encoder and stream the SteamVR compositor to the headset. Unsupported or inconsistent video capabilities should return an initialization error instead of crashing vrserver.

Actual behavior

The network session is established, the PICO HMD and both controllers are activated, and a Vulkan device/video encode queue is created on the NVIDIA GPU. vrserver then receives SIGSEGV immediately after VRLink reports 10-bit and ultra-low-latency support and selects rate-control mode 4.

System information

• Steam client build: 1785799196 (observed in the running Steam client command line)
• SteamVR versions reproduced:
  • 2.16.7 stable
  • 2.17.6 beta, app build ID 23791826, beta key public
• Distribution: Kylin Linux Desktop V10 SP1, x86_64
• Kernel: 5.4.18-142-generic #131-KYLINOS
• Desktop session: X11
• GPU: NVIDIA GeForce RTX 5060, 8 GB
• NVIDIA driver: 595.80, open kernel module
• Headset: PICO 4 Enterprise
• PICO Steam Link/VRLink client string: qvlclient;PICO 4 Enterprise;2.0.22.2145
• Requested render target: 2048x2048
• Headset-reported refresh rate: approximately 72.004608 Hz

Current SteamVR 2.17.6 binary hashes:

d68abbcb84ffebeff127533396201f7c8d41191998dba73aaa0a670072ee3890  driver_vrlink.so
67b078a04467c191ae18bfee6bc5137bfaf3141e648db71e805d5a1b95a6c3b4  vrserver

Relevant VRLink log immediately before the 2.17.6 crash

[HMDVulkan] Activate()
[HMDVulkan] Created instance
[HMDVulkan] CreateVulkanDevice()
[HMDVulkan] 2 physical devices available
[HMDVulkan] Found 2 candidate devices
[HMDVulkan] Checking device 'NVIDIA GeForce RTX 5060' with driver 'NVIDIA'
[HMDVulkan] Using device 'NVIDIA GeForce RTX 5060' with driver 'NVIDIA'
[HMDVulkan] Got VkInstance + VkPhysicalDevice
[HMDVulkan] Found dedicated async compute queue
[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
Default automatic encoded video size: 1024
[VideoVulkan] Setting video capabilties: 10bit: Yes, ull: Yes

There is no later VideoVulkan success/error message. The process dumps core at this point.

2.17.6 coredump backtrace

PID: 44550 (vrserver)
Signal: 11 (SEGV)
Timestamp: Mon 2026-08-10 17:41:40 CST

Stack trace of thread 44550:
#0  libvulkan.so.1.3.239 + 0x46764
#1  driver_vrlink.so + 0x1033fc
#2  vrserver + 0x3ec34f
#3  vrserver + 0x23f46b
#4  vrserver + 0x23f8ae
#5  vrserver + 0x23fdf9
#6  vrserver + 0x24098b
#7  vrserver + 0x245f31
#8  vrserver + 0x246e8b
#9  libc-2.31.so + 0x24383

Independent reproduction on SteamVR 2.16.7

Two earlier runs on 2.16.7 crashed at the same stage and produced the same stack shape:

2026-08-10 16:53:57 CST: vrserver, SIGSEGV
#0 libvulkan.so.1.3.239 + 0x46764
#1 driver_vrlink.so + 0xfe9fc
#2 vrserver + 0x3c35cf

2026-08-10 17:12:31 CST: vrserver, SIGSEGV
#0 libvulkan.so.1.3.239 + 0x46764
#1 driver_vrlink.so + 0xfe9fc
#2 vrserver + 0x3c35cf

The changed driver_vrlink.so offset in 2.17.6 (0x1033fc) is expected from the updated binary, while the failure remains at the same Vulkan-video initialization stage.

Evidence that discovery/networking succeeded

Before the crash, the log confirms:

SVLDataLinkUber: Found primary link [redacted]
ReceivedHMDStaticProps. Model Number: PICO 4 Enterprise
Ready to activate controller ... Left
Ready to activate controller ... Right
SVLDriver::ActivateHMDNow()
Render Target: 2048 2048
Display Frequency: 72.004608

This makes a headset-discovery or basic network-connectivity failure unlikely.

Other loader messages

The host has stale ICD JSON files for GPUs that are not installed. The Vulkan loader logs failures for their missing libraries, plus old Intel/RADV ICD interface warnings. However, VRLink continues past those messages, explicitly selects the RTX 5060, creates the Vulkan instance/device, and finds a video-encode queue before crashing:

loader_icd_scan: Failed loading library associated with ICD JSON libvlk_xdxgpu.so. Ignoring this JSON
loader_icd_scan: Failed loading library associated with ICD JSON libVK_MT.so. Ignoring this JSON
loader_icd_scan: Failed loading library associated with ICD JSON libVK_INNO.so. Ignoring this JSON

These messages may still be relevant if VRLink retains capability data from more than the selected physical device.

Additional observations

• The headset reports only 72 Hz entries, while VRLink initially requests a preferred 90 Hz. VRLink subsequently receives VTE_REQ_FRAMETIME_US = 13888 and reports the final display frequency as 72.004608 Hz.
• PipeWire connection also fails, but the fatal stack is in Vulkan/VRLink rather than audio code.
• SteamVR 2.17.6 improves GPU selection: the log confirms that the intended RTX 5060 is selected.
• No compositor is launched before the crash because vrserver dies during HMD/encoder activation.

Requested investigation

Could Valve please symbolicate driver_vrlink.so + 0x1033fc for SteamVR 2.17.6 build 23791826 and verify the return values/pointers used after video capability selection, especially around 10-bit, ultra-low-latency, and rate-control mode 4?

Full Steam/SteamVR logs and the compressed vrserver coredump can be provided privately if required. They are not attached publicly here because they contain local identifiers and network information.