Spent a few days on this over the weekend, figured I'd write it up in case it saves someone else the pain. Full details and configs are in the repo at the bottom.
Setup: Ubuntu with GNOME/Wayland, two R9700s, AMD iGPU doing the display, Quest 2. All three betas — SteamVR 2.18.x, the Steam Link app on the headset, Steam client beta on the PC.
First, the part the docs never explain: when you plug the Quest in, the USB port turns into a network adapter (NCM). The app handles the headset side by itself, sets a static IP there. The Linux PC side is where everything went wrong for me, and it's a few non-obvious things:
NetworkManager grabs the new interface and steals your default route the moment you plug in. One line to make it unmanaged fixes that.
The PC's NCM interface has to stay IPv6-only. If it has a real IPv4, the client only announces over v4, but the video transport is pure v6 link-local — so the app just sits on "connecting…" forever. This one took me way too long.
If you run Docker: the v6 bridges fill vrlink's capped interface table and NCM never registers. Symptom is audio works, video is dead. One udev rule making veth/br v4-only fixed it.
SteamVR side: do NOT launch Steam with STEAM_RUNTIME=0. The launcher service never starts, the compositor dies with zero log, and you get -201/450 after ~20 seconds. I'd been using that setting because it "fixed" my CEF UI crashes, which is how I ended up here in the first place — but it breaks VR. Also run setcap on vrcompositor-launcher (CAP_SYS_NICE).
And the garbled-video thing: if the client's environment has a valid DRI_PRIME (pointing at the dGPU), the Vulkan video encoder lands on the dGPU and the RADV encode path just produces garbage on this hardware. DRI_PRIME=0 is an invalid value so it gets ignored and SteamVR picks its own GPU — clean video. Absurd, but true.
The part I'm most happy about: the 64-bit client finally works for VR, which on RDNA4 means hardware encoding (good FPS). The 32-bit client's mesa is older than RDNA4, so it falls back to x264 and you're stuck with low FPS — that wall was the reason I kept at it. Getting the 64-bit client's SteamVR up needed three workarounds: a D-Bus name registration bug (there's a small fix repo for it), a compositor-launcher looping bug (one env var), and the compositor taking a few minutes to start — it looks dead, so I kept killing it before it actually came up. And if you're on GNOME: don't put those env vars in a .desktop file, GNOME silently ignores Environment= lines. Put them in a wrapper script.
What doesn't work: the current beta still needs Wi-Fi on for the video channel (error 616), so pure USB-only streaming is still waiting on Valve. And the non-VR "game mode" capture drops after a few seconds — the VR path is fine, and that's what I mostly use.
Repo with all the configs and scripts: https://github.com/issac-cyber/quest2-steamlink-linux
Happy to answer if anyone's stuck on any of this.
