@kisak-valve, I've done multiple troubleshooting sessions and finally found the cause and a functional workaround for this issue. The last session involved deep manual troubleshooting using an AI. Below the summary of my chat (done by that AI) with all the relevant details. I've read carefully through it, but didn't execute the commands again for obvious reasons, so take care when following the steps.
See also https://github.com/ValveSoftware/SteamVR-for-Linux/issues/1004#issuecomment-6163527331 of
In fact I've done all homework for Valve and the solution is trivial: For SteamOS, update the Vangogh VCN encoder firmware file from 1.27 to at least 1.33. Do I get any reward 😜 ?
On my Steam Deck, replacing the loaded Vangogh VCN encoder firmware 1.27 with upstream firmware 1.33, using a separate firmware override, resolved:
After the firmware change, Vulkan HEVC encoding is exposed without an experimental environment variable. Dashboard streaming and several Battle Talent sessions of approximately 15 minutes each worked without the previous extreme blockiness or obvious critical failures during gameplay.
Some issues remain, documented below. This is a working local workaround, not yet a fix delivered through SteamOS.
AMD Custom GPU 0405 (RADV VANGOGH).Mesa 26.2.0-devel (git-5c65d4fc31).7.2.7-valve2-2-neptune-72-g31504582a073.linux-firmware-neptune jupiter.20260910.1-1.SteamVR reported:
No HEVC support
No Vulkan Video device supporting HEVC encoding was detected.
(1204)
The relevant server log was explicit:
Checking device 'AMD Custom GPU 0405 (RADV VANGOGH)' with driver 'radv'
Rejecting driver 'radv' as it does not seem to support Vulkan Video
Failed to create device... Exiting...
VRInitError_VendorSpecific_VRLink_NoEncoderSupport
FFmpeg successfully encoded HEVC Main and Main 10 through VA-API, but vulkaninfo did not expose the required Vulkan Video encoding extensions. VA-API functionality therefore did not establish Vulkan Video availability.
RADV reported:
vcn_enc_major_version = 1
vcn_enc_minor_version = 27
vcn_dec_version = 2
In the examined Mesa source, regular video-encoding enablement depends on radv_video_write_memory_supported(). For VCN 3.x, that check requires an encoder firmware minor version of at least 33. The source explains that WRITE_MEMORY is needed for SetEvent and conformance testing.
Setting:
RADV_EXPERIMENTAL=video_encode
exposed the encoding extensions and allowed a short FFmpeg Vulkan HEVC test to complete. However, SteamVR streaming then produced extremely blocky images, including in the dashboard.
The experimental path also produced timeline/frame-state assertions and one confirmed vrserver SIGSEGV. Debug symbols identified the crash site as:
vk_common_ResetCommandBuffer()
src/vulkan/runtime/vk_command_buffer.c:135
The indirect reset call used an invalid command-buffer ops pointer. The origin of that invalid pointer was not established.
Validation-layer testing additionally reported:
VUID-VkSemaphoreTypeCreateInfo-timelineSemaphore-03252
VUID-VkShaderModuleCreateInfo-pCode-08740
VUID-VkShaderModuleCreateInfo-pCode-08742
VUID-vkCmdDraw-None-09600
VUID-vkCmdBeginVideoCodingKHR-pBeginInfo-08253
The last error explicitly concerned VRLink_VideoSession: its configured rate-control mode was VBR, but vkCmdBeginVideoCodingKHR omitted VkVideoEncodeRateControlInfoKHR. These findings do not establish which error caused the crash or image degradation.
The sequence closely resembles the [firmware-related report in #1004](https://github.com/ValveSoftware/SteamVR-for-Linux/issues/1004#issuecomment-6163527331):
That report concerns different AMD hardware. Its vcn_4_0_0.bin file must not be substituted for the Deck’s Vangogh firmware.
Other participants in [#1004](https://github.com/ValveSoftware/SteamVR-for-Linux/issues/1004) report similar image degradation despite encoding already being exposed normally. Consequently, this workaround should not be assumed to explain every case in #1004.
The installed firmware package passed its local integrity check. The local and upstream amdgpu/vangogh_vcn.bin nevertheless differed:
| Firmware | Encoder | Decoder | SHA-256 of uncompressed file |
|---|---|---|---|
| Installed SteamOS file | 1.27 | 2 | a16b7170dd9c21505c53057b2a4f76930af6527654e6d1f90955fde44786e4fb |
| Tested upstream file | 1.33 | 4 | 3d282b29bff2ea1833e00cfb08bb6dd9b379f7e58090e0e87aaccb4c2a35d732 |
After installing the override and rebooting:
vcn_enc_major_version = 1
vcn_enc_minor_version = 33
vcn_dec_version = 4
VK_KHR_video_encode_h265
VK_KHR_video_encode_queue
These extensions appeared without experimental enablement.
With RADV_EXPERIMENTAL=video_encode removed from SteamVR’s launch options:
Some reduced image quality remains. Its cause has not been measured; attributing it specifically to 2.4 GHz Wi-Fi would currently be speculation.
vrcompositor reproducibly aborts when manually exiting SteamVR, after gameplay has ended. Its stack includes __cxa_pure_virtual and abort, unlike the earlier vrserver SIGSEGV.steamwebhelper also aborted on one observed occasion. A causal relationship with the compositor shutdown failure is unproven.vrserver crash has not recurred in the reported successful sessions, but its permanent resolution is not established.These should be tracked separately from the resolved encoder-availability/image-corruption problem. “Separate investigation” does not imply proven independence.
The successful comparison initially retained Vulkan validation/debug instrumentation. Reproduction of the remaining issues without that instrumentation is still needed.
Warning: This is a manual system modification, not an official SteamOS update. A firmware initialization failure can affect graphics or boot usability. Have a tested Linux live USB capable of mounting the Deck’s Btrfs partition before proceeding.
This does not flash the GPU or update the BIOS. Linux loads the firmware file into the VCN hardware during initialization.
Run in the Deck’s desktop terminal:
mkdir -p "$HOME/vcn-firmware-test"
curl -fL 'https://gitlab.com/kernel-firmware/linux-firmware/-/raw/main/amdgpu/vangogh_vcn.bin' -o "$HOME/vcn-firmware-test/vangogh_vcn.bin"
printf '%s\n' "3d282b29bff2ea1833e00cfb08bb6dd9b379f7e58090e0e87aaccb4c2a35d732 $HOME/vcn-firmware-test/vangogh_vcn.bin" | sha256sum -c
Proceed only if this reports OK. The upstream main branch can change. A different hash means the file is no longer the exact candidate tested here; do not assume this report validates it. This hash comparison is not a signature verification.
The override belongs under:
/usr/lib/firmware/updates/amdgpu/vangogh_vcn.bin
It takes precedence over the original firmware while leaving the package-managed file untouched.
First check for an existing override:
ls -ld /usr/lib/firmware/updates /usr/lib/firmware/updates/amdgpu /usr/lib/firmware/updates/amdgpu/vangogh_vcn.bin
Missing paths are expected on the tested system. If the target file already exists, stop and investigate rather than overwrite it.
Run the following commands individually. Stop on errors, and restore SteamOS read-only protection even if copying fails:
sudo steamos-readonly disable
sudo mkdir -p /usr/lib/firmware/updates/amdgpu
sudo cp "$HOME/vcn-firmware-test/vangogh_vcn.bin" /usr/lib/firmware/updates/amdgpu/vangogh_vcn.bin
sudo chown root:root /usr/lib/firmware/updates/amdgpu/vangogh_vcn.bin
sudo chmod 0644 /usr/lib/firmware/updates/amdgpu/vangogh_vcn.bin
sudo steamos-readonly enable
Verify the destination hash and protection status:
sha256sum /usr/lib/firmware/updates/amdgpu/vangogh_vcn.bin
steamos-readonly status
The expected hash is listed above; protection should report enabled.
On this tested Deck, no VCN firmware was found in the inspected initramfs, and no initramfs rebuild was performed. Other boot configurations may differ.
After reboot, before starting SteamVR:
env -u RADV_EXPERIMENTAL -u RADV_PERFTEST -u RADV_DEBUG -u RADV_QUEUE_DISABLE RADV_DEBUG=info vulkaninfo 2>&1 | grep -E 'vcn_enc_major_version|vcn_enc_minor_version|vcn_dec_version|VK_KHR_video_encode_h265|VK_KHR_video_encode_queue'
Expected: encoder 1.33, decoder 4, and the encoding extensions.
Remove the experimental encoder-enablement option from SteamVR’s launch options. No validation-layer setup is required to apply this firmware workaround.
Test dashboard streaming first, then a game, leaving network and quality settings unchanged for comparison.
The override persists across reboots until removed. From a working SteamOS session:
sudo steamos-readonly disable
sudo rm /usr/lib/firmware/updates/amdgpu/vangogh_vcn.bin
sudo steamos-readonly enable
Reboot to use the original firmware again.
If SteamOS cannot be used, boot the tested Linux live USB, mount the correct SteamOS partition read-write, and delete only that override file beneath the mount point. Do not delete the original amdgpu/vangogh_vcn.bin.zst.
Please update the Vangogh VCN firmware shipped in the official SteamOS firmware package, or provide an officially supported update path.
On this Deck, SteamOS’ packaged encoder firmware 1.27 failed the examined RADV driver’s regular Vulkan Video enablement check. The tested upstream 1.33 firmware:
Please validate and ship an appropriate Vangogh firmware revision so users do not need to disable SteamOS protection or maintain a manual override. This local test supports an official update, while not replacing Valve’s broader compatibility testing.
RADV_DEBUGx1 2026-10RADV_DEBUG=infox1 2026-10RADV_EXPERIMENTALx1 2026-10RADV_EXPERIMENTAL=video_encodex1 2026-10RADV_PERFTESTx1 2026-10RADV_QUEUE_DISABLEx1 2026-10
Steam Deck Details
SteamOS 3.9.4 Build: 20261021.100 (Beta)
Steam-Betabranch: Steam Deck Beta
Steam-Version: 1792626604
Steam-Client: Build-Datum: Do., 22. Okt. 2026 1:19 UTC +02:00
Datum des Steam-Web-Builds: Do., 22. Okt. 2026 0:28 UTC +02:00
Steam-API-Version: SteamClient023
Steam Frame Details
SteamOS 0.5.6 (Beta)
Works (despite video artifacts caused by slow connection)
Connection: Steam Deck - LAN 1 GB - Router - WLAN 2,4 GHz - Steam Frame
Streaming In both directions:
Desktop Steam Deck <-> Steam Frame
Subnautica 2D Steam Deck <-> Steam Frame
Does NOT work
VR Streaming at all with every connection combination/setting I've tried - of course also using the wifi adapter included with the Steam Frame, even when plugged directly into the USB-C port of the Steam Deck.
IMPORTANT
VR Streaming works when using a Linux laptop I have instead of the Steam Deck - after correcting the regulatory domain for the wifi frequencies to DE. System details in https://github.com/ValveSoftware/steam-for-linux/issues/9273#issuecomment-6110819284. For troubleshooting I've used
https://github.com/ValveSoftware/SteamVR-for-Linux/blob/master/frame-dongle-troubleshoot.sh
Output on the Steam Deck after correction to DE with
sudo iw reg set DE:I've also set up firewall rules, but these may have been to restrictive.
I know that the Steam Deck is quite weak, but it's more powerful than the Steam Frame and has at least one translation layer less for most of the games. I've tried Battle Talent (a Windows VR Game) directly on the Frame and after turning the quality a bit down it's "okayish" despite a slight controller delay.
Both products are made by Valve, so I cannot imagine this functionality is untested, but I didn't find any hint/documentation.
At least the requirements including the network ones must get documented somewhere. As of now, it's completely intransparent how the setup of the included wifi adapter works and how (network) security is affected. Every time the adapter is plugged in, it enables IPv6 again, where the secrets/wifi passwords come from is undocumented and an internet connection is mandatory despite functional not necessary because it's a direct connection PC <-> Steam Frame (which could be set up either manually or by connecting both to the same home network, not necessarily to the internet).