I'm encountering the same problem on arch linux,
Any VR stream displays with the same unplayable level of compression as the above screenshots, with the proper refresh rate and no noticeable latency.

My wireless adapter seems to function properly, though connecting via wifi, adapter, USB tethering, or any combination of multi-link streaming makes no change to the image quality.

At least in my case, streaming flat-screen desktop games to the frame to play in theater mode works normally.

I also tried streaming from an old windows 10 install in case this was some kind of hardware issue, but VR streaming worked as expected there.

Desktop:

• Distribution: Arch Linux | Kernel 7.2.9-arch1-1
• GPU: AMD Radeon RX 5700 XT
• Graphics Driver: mesa 1:26.2.4-1
• Steam Client Version: 1791415817 | Wed, Oct 7, 2026 18:46 UTC -04:00 (Steam Client Beta)
• SteamVR Version: 2.18.2 (1790893534) | Built Oct 1, 2026 at 18:25

Frame:

• OS Version: 0.4.5
• OS Build: 20261007.6125817
• Steam Version: 1791328779
• SteamVR Version: 2.18.2

Updated information:

I have learned how to use WiVRn as an alternative to SteamVR, and WiVRn is not affected by this problem for me, so I can now play PCVR on my Steam Frame through WiVRn, including through the Steam Frame Wireless Adapter, without having any bitrate problem.

However, I will continue to test SteamVR in the future if SteamVR gets updates that might fix the problem, because SteamVR and WiVRn seem to have slightly different features.

The setup of WiVRn on Steam Frame and Gentoo PC is very complicated, but I was able to do it. I have not explained exactly how I set it up, but could if someone needs an explanation.

Had the exact same thing on Nobara (kernel 7.2.8, RX 7800 XT, Mesa 26.2.4) and got it fixed with some help from an LLM. Posting in case it's the same cause for others on AMD.

The problem was the VCN firmware. Mine was really old: dmesg showed ENC: 1.13 DEC: 5, file dated Feb 2024. It came from an old amd-gpu-pro-firmware 5.7.2 package that Nobara's codec wizard had installed at some point (AMF stuff). That package also "provides" amd-gpu-firmware, so the normal firmware package never got installed and the VCN firmware was never updated.

With firmware that old, RADV doesn't expose Vulkan video encode, so at first I couldn't stream at all. The game would start on the PC and the Frame complained the account was in use somewhere else. Forcing it with RADV_PERFTEST=video_encode got streaming going, but that's when I got the super pixelated image from this issue. Turns out RADV hides encode on old firmware for a reason.

Fix was putting the current firmware from linux-firmware where the kernel looks first:

sudo mkdir -p /lib/firmware/updates/amdgpu
curl -L -o /tmp/vcn_4_0_0.bin https://gitlab.com/kernel-firmware/linux-firmware/-/raw/main/amdgpu/vcn_4_0_0.bin
sudo cp /tmp/vcn_4_0_0.bin /lib/firmware/updates/amdgpu/

Reboot, drop the RADV_PERFTEST variable, and the stream is sharp now. vcn_4_0_0.bin is the one for Navi 31/32, other cards may load a different file.

Quick way to check if you're hitting the same thing:

sudo dmesg | grep -i "vcn.*firmware"
vulkaninfo 2>/dev/null | grep video_encode_h265   # with RADV_PERFTEST unset

If the second command prints nothing, your VCN firmware is probably too old. On Nobara the cleaner fix is probably removing the AMD Pro codecs through the codec wizard and then installing amd-gpu-firmware (a manual dnf remove gets blocked), but I haven't done that part yet.

OP, what GPU are you on? On Gentoo the package part won't apply, but the firmware check should.

We both who posted first have RX 5700 XT, which is visible in our reports. here is the result on my computer of the commands you posted

tacokoneko@CORSAIR ~ $ sudo dmesg | grep -i "vcn.*firmware"
tacokoneko@CORSAIR ~ $ vulkaninfo 2>/dev/null | grep video_encode_h265   # with RADV_PERFTEST unset
	VK_KHR_video_encode_h265                      : extension revision 14
tacokoneko@CORSAIR ~ $ 

I have the same problem. Also got a RX 5700 XT and know of at least 2 others with the same GPU and the same problem...

Same thing on Nobara with an RX 5700 XT :/

@robertkirkman would you mind sharing how you got the wivrn client running on the frame? I grabbed the frame binaries from the build action artifacts of the project repo, but it refuses to run on the frame.

Here are screenshots of the relevant settings I am using in the Steam entry for it:

if you have these set and it's still not working, or you have difficulty connecting it to the PC after launching it, I will make a more complete tutorial.

Copying what I posted in #904 , although this thread seems more relevant so I'll keep posting here. Seeing the same blurry VR streaming, changed tons of settings, no luck. Flatscreen streaming to my Frame from the same desktop doesn't have the same problem.

I'd like to add that I've had this issue with the Steam Frame, streaming from my CachyOS desktop (with a AMD Radeon RX 5700 XT as well). Just to double check any other potential streaming issues on the frame, I've ran https://github.com/ValveSoftware/SteamVR-for-Linux/issues/904 and all else is well with my setup that I can tell. Vulkan driver issue would make sense since I've had issues with Vulkan in the past... I'll try messing with my drivers and see if I make any progress

Now as for this post:

Had the exact same thing on Nobara (kernel 7.2.8, RX 7800 XT, Mesa 26.2.4) and got it fixed with some help from an LLM. Posting in case it's the same cause for others on AMD.
The problem was the VCN firmware. Mine was really old: dmesg showed ENC: 1.13 DEC: 5, file dated Feb 2024. It came from an old amd-gpu-pro-firmware ...
...

Unfortunately, I don't think this is the case for me, I do get VK_KHR-video_encode_h265 : extension revision 14 on your quick check command. I am on VCN firmware enc: 1.24 and dec: 8, and I've verified that it's coming from linux-firmware-amdgpu recently installed. I can't seem to find what the latest numbers for that should be for Radeon RX 5700 XT though...

So far, what I've checked on my system seems to indicate:

• The driver exposes H.264 and H.265 encode.
• The Vulkan encoder initializes successfully.
• Firmware is current and correctly packaged.
• The network is fine, with no packet loss or lag.
• Changing the codec toggles, resolution and encode width had no effect.

Something interesting worth mentioning, not sure if it's related, but logs show the following:

chosen m_MaxSVLVideoExtent: 3200x4096
Resize: 1024 4096

And all future logs show it staying with that 1024 4096, not sure if that's low or not. Figured I'd mention in case it is, but the picture is so blurry that it's probably unrelated.

Will keep looking for clues.

Final bit of digging from me for now, looking at the logs and doing some tests with FFMPEG to rule out driver issues:

• vrlink logs: Vulkan Video init succeeds, rate control mode 4, encode surface 1024x4096
• Actual stream bitrate about 2.3 Mbps at 90 fps, unchanged by manually changing bitrate settings
• Testing with ffmpeg videos to see if vulkan correctly handles 10-bit, VBR -tune ull, and/or 1024x4096 on my AMD Radeon RX 5700 XT with my current drivers: Here's the actual commands I ran:

cd /tmp
ffmpeg -y -loglevel error -init_hw_device vulkan=vk -filter_hw_device vk -f lavfi -i mandelbrot=s=1920x1080:r=60 -t 10 -vf "format=nv12,hwupload" -c:v hevc_vulkan -b:v 5M /tmp/base_5M.mkv
ffmpeg -y -loglevel error -init_hw_device vulkan=vk -filter_hw_device vk -f lavfi -i mandelbrot=s=1920x1080:r=60 -t 10 -vf "format=nv12,hwupload" -c:v hevc_vulkan -b:v 50M /tmp/base_50M.mkv
ffmpeg -y -loglevel error -init_hw_device vulkan=vk -filter_hw_device vk -f lavfi -i mandelbrot=s=1024x4096:r=90 -t 10 -vf "format=nv12,hwupload" -c:v hevc_vulkan -b:v 5M /tmp/tall_5M.mkv
ffmpeg -y -loglevel error -init_hw_device vulkan=vk -filter_hw_device vk -f lavfi -i mandelbrot=s=1024x4096:r=90 -t 10 -vf "format=nv12,hwupload" -c:v hevc_vulkan -b:v 50M /tmp/tall_50M.mkv
ffmpeg -y -loglevel error -init_hw_device vulkan=vk -filter_hw_device vk -f lavfi -i mandelbrot=s=1920x1080:r=90 -t 10 -vf "format=p010,hwupload" -c:v hevc_vulkan -profile:v main10 -b:v 5M /tmp/tenbit_5M.mkv
ffmpeg -y -loglevel error -init_hw_device vulkan=vk -filter_hw_device vk -f lavfi -i mandelbrot=s=1920x1080:r=90 -t 10 -vf "format=p010,hwupload" -c:v hevc_vulkan -profile:v main10 -b:v 50M /tmp/tenbit_50M.mkv
ffmpeg -y -loglevel error -init_hw_device vulkan=vk -filter_hw_device vk -f lavfi -i mandelbrot=s=1920x1080:r=90 -t 10 -vf "format=nv12,hwupload" -c:v hevc_vulkan -rc_mode vbr -tune ull -b:v 5M /tmp/vbrull_5M.mkv
ffmpeg -y -loglevel error -init_hw_device vulkan=vk -filter_hw_device vk -f lavfi -i mandelbrot=s=1920x1080:r=90 -t 10 -vf "format=nv12,hwupload" -c:v hevc_vulkan -rc_mode vbr -tune ull -b:v 50M /tmp/vbrull_50M.mkv
ffmpeg -y -loglevel error -init_hw_device vulkan=vk -filter_hw_device vk -f lavfi -i mandelbrot=s=1024x4096:r=90 -t 10 -vf "format=p010,hwupload" -c:v hevc_vulkan -profile:v main10 -rc_mode vbr -tune ull -b:v 5M /tmp/all_5M.mkv
ffmpeg -y -loglevel error -init_hw_device vulkan=vk -filter_hw_device vk -f lavfi -i mandelbrot=s=1024x4096:r=90 -t 10 -vf "format=p010,hwupload" -c:v hevc_vulkan -profile:v main10 -rc_mode vbr -tune ull -b:v 50M /tmp/all_50M.mkv
ls -l /tmp/*_5M.mkv /tmp/*_50M.mkv

with results seemingly working as they should, all the 50M tests are about ~10x the size of their 5M test counterparts. That seems to imply to me that Vulkan is working correctly on my machine, but I can't say for sure of course, this is just testing based on guesses on how SteamVR is using Vulkan via logs and settings. Hope any of this is helpful!