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
- Start Steam and SteamVR on the Linux host.
- Start Steam Link on a PICO 4 Enterprise on the same LAN.
- Connect the headset to the host.
- Wait for VRLink to discover the headset and controllers.
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 stable2.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.
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,
vrserverterminates withSIGSEGV.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 fromdriver_vrlink.so, followed byvrserver.To reproduce
vrservercrashes 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.
vrserverthen receivesSIGSEGVimmediately after VRLink reports 10-bit and ultra-low-latency support and selects rate-control mode 4.System information
1785799196(observed in the running Steam client command line)2.16.7stable2.17.6beta, app build ID23791826, beta keypublic5.4.18-142-generic #131-KYLINOS595.80, open kernel moduleqvlclient;PICO 4 Enterprise;2.0.22.21452048x204872.004608 HzCurrent SteamVR 2.17.6 binary hashes:
Relevant VRLink log immediately before the 2.17.6 crash
There is no later
VideoVulkansuccess/error message. The process dumps core at this point.2.17.6 coredump backtrace
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:
The changed
driver_vrlink.sooffset 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:
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:
These messages may still be relevant if VRLink retains capability data from more than the selected physical device.
Additional observations
VTE_REQ_FRAMETIME_US = 13888and reports the final display frequency as 72.004608 Hz.vrserverdies during HMD/encoder activation.Requested investigation
Could Valve please symbolicate
driver_vrlink.so + 0x1033fcfor SteamVR 2.17.6 build23791826and 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
vrservercoredump can be provided privately if required. They are not attached publicly here because they contain local identifiers and network information.