SteamVR-2026-09-07-PM_10_26_27.txt
DESCRIBE THE BUG
Connecting a Meta Quest 3S via Steam Link VR on Linux fails during driver_vrlink
Vulkan device creation. vkCreateDevice returns -7 (VK_ERROR_EXTENSION_NOT_PRESENT),
the compositor never initialises, and SteamVR shows:
SteamVR Graphics Error
You may need to update your computer's graphics driver.
(405)
The network connection itself succeeds - the log shows "Connection active at
72.419720" and the headset is correctly identified - so this is purely the Vulkan
device creation path.
The driver never reaches the point of creating a VkDevice, so it never reports a
Video Encode Queue Family (unlike the working case shown in issue #898).
SYSTEM INFORMATION
Distro: Pop!_OS 24.04 LTS
Kernel: 7.1.5-76070105-generic
GPU: NVIDIA GeForce GTX 1660 SUPER (TU116, Turing), 6 GB
NVIDIA driver: 580.173.02
Kernel modules: open (modinfo nvidia -> license: Dual MIT/GPL)
SteamVR: beta 2.17.8 (Sep 1 2026) AND Default Public (Jun 18 2026)
- both fail identically
Headset: Meta Quest 3S, Horizon OS v207
Connection: Steam Link over Wi-Fi 6 (5 GHz, 1200 Mbit link),
host on gigabit Ethernet
LOG EXCERPT
[Info] - vrlink: Autodetected Headset, using Oculus Quest 3 profile
[Info] - vrlink: SVLHMDDriver::Activate: HMD supports multiple framerates
[Info] - vrlink: [HMDVulkan] Activate()
[Info] - vrlink: [HMDVulkan] Created instance
[Info] - vrlink: [HMDVulkan] CreateVulkanDevice()
[Info] - vrlink: [HMDVulkan] 2 physical devices available
[Info] - vrlink: [HMDVulkan] Found 1 candidate devices
[Info] - vrlink: [HMDVulkan] Checking device 'NVIDIA GeForce GTX 1660 SUPER' with driver 'NVIDIA'
[Info] - vrlink: [HMDVulkan] Using device 'NVIDIA GeForce GTX 1660 SUPER' with driver 'NVIDIA'
[Info] - vrlink: [HMDVulkan] VRSystem adapter LUID set to 0xc60f3f063f4a1cc
[Info] - vrlink: [HMDVulkan] Got VkInstance + VkPhysicalDevice
[Info] - vrlink: [HMDVulkan] Found regular graphics queue!
[Info] - vrlink: [HMDVulkan] Failed to create device: -7
[Info] - vrlink: [HMDVulkan] Failed to create device... Exiting...
[Info] - vrlink: [HMDVulkan] Deactivate()
[Info] - vrlink: [HMDVulkan] DestroyEncodeBackbuffers
[Warning] - Could not activate pending device VRLINKHMDQUEST3S: VRInitError_Compositor_UnableToCreateDevice
[Info] - vrlink: Connection active at 72.419720
VULKAN VIDEO ENCODE EXTENSIONS ARE PRESENT
Output of: vulkaninfo | grep -iE "video_encode|video_queue"
VK_KHR_video_encode_h264 : extension revision 14
VK_KHR_video_encode_h265 : extension revision 14
VK_KHR_video_encode_quantization_map : extension revision 2
VK_KHR_video_encode_queue : extension revision 12
VK_KHR_video_queue : extension revision 8
queueFlags = QUEUE_TRANSFER_BIT | QUEUE_SPARSE_BINDING_BIT | QUEUE_VIDEO_ENCODE_BIT_KHR
So H.264/H.265 Vulkan Video encode and a video-encode-capable queue family are both
exposed by the driver. Whatever extension driver_vrlink is requesting, it isn't one
of these.
VK_KHR_video_encode_av1 is NOT present - expected, since Turing NVENC predates AV1
encode hardware. If vrlink requests AV1 encode unconditionally on this code path,
that would explain the failure on any pre-Ada NVIDIA GPU. This is speculation, but
it is the only video encode extension absent from an otherwise complete set.
THINGS RULED OUT
- SteamVR beta 2.17.8: fails, -7
- SteamVR Default Public (Jun 18 2026): fails identically, -7
- VK_DRIVER_FILES=/usr/share/vulkan/icd.d/nvidia_icd.json:
queue selection changed from "Found regular graphics queue!" to
"Found dedicated async compute queue" - still fails with -7
- GPU selection: correct. The April 2026 open-driver enumeration fix works;
the 1660 SUPER is chosen properly.
- Network / pairing: fine. "Connection active at 72.42", 0% packet loss to
the headset.
The fact that -7 persists across two different queue configurations suggests the
missing extension is not queue-related.
TO REPRODUCE
- Turing-generation NVIDIA GPU (no AV1 encode), open kernel modules,
driver 580.173.02
- Start SteamVR on the Linux host
- Launch Steam Link on a Quest 3S and connect
- Device creation fails with -7; error 405 on the host
EXPECTED BEHAVIOUR
driver_vrlink should either negotiate an extension set the device actually supports,
or log which extension was requested and not found so this is diagnosable without
Vulkan API tracing.
SteamVR-2026-09-07-PM_10_26_27.txt
DESCRIBE THE BUG
Connecting a Meta Quest 3S via Steam Link VR on Linux fails during driver_vrlink
Vulkan device creation. vkCreateDevice returns -7 (VK_ERROR_EXTENSION_NOT_PRESENT),
the compositor never initialises, and SteamVR shows:
The network connection itself succeeds - the log shows "Connection active at
72.419720" and the headset is correctly identified - so this is purely the Vulkan
device creation path.
The driver never reaches the point of creating a VkDevice, so it never reports a
Video Encode Queue Family (unlike the working case shown in issue #898).
SYSTEM INFORMATION
Distro: Pop!_OS 24.04 LTS
Kernel: 7.1.5-76070105-generic
GPU: NVIDIA GeForce GTX 1660 SUPER (TU116, Turing), 6 GB
NVIDIA driver: 580.173.02
Kernel modules: open (modinfo nvidia -> license: Dual MIT/GPL)
SteamVR: beta 2.17.8 (Sep 1 2026) AND Default Public (Jun 18 2026)
- both fail identically
Headset: Meta Quest 3S, Horizon OS v207
Connection: Steam Link over Wi-Fi 6 (5 GHz, 1200 Mbit link),
host on gigabit Ethernet
LOG EXCERPT
VULKAN VIDEO ENCODE EXTENSIONS ARE PRESENT
Output of: vulkaninfo | grep -iE "video_encode|video_queue"
So H.264/H.265 Vulkan Video encode and a video-encode-capable queue family are both
exposed by the driver. Whatever extension driver_vrlink is requesting, it isn't one
of these.
VK_KHR_video_encode_av1 is NOT present - expected, since Turing NVENC predates AV1
encode hardware. If vrlink requests AV1 encode unconditionally on this code path,
that would explain the failure on any pre-Ada NVIDIA GPU. This is speculation, but
it is the only video encode extension absent from an otherwise complete set.
THINGS RULED OUT
queue selection changed from "Found regular graphics queue!" to
"Found dedicated async compute queue" - still fails with -7
the 1660 SUPER is chosen properly.
the headset.
The fact that -7 persists across two different queue configurations suggests the
missing extension is not queue-related.
TO REPRODUCE
driver 580.173.02
EXPECTED BEHAVIOUR
driver_vrlink should either negotiate an extension set the device actually supports,
or log which extension was requested and not found so this is diagnosable without
Vulkan API tracing.