Host

• Steam client: 1788652215 (stable), started with -pipewire -vrlinkforceenable
• SteamVR: 2.17.10 stable (build 1789498647)
• Distribution: Linux Mint 22.3 (Ubuntu 24.04 base), kernel 7.0.0-34-generic, X11 / Cinnamon
• GPU: NVIDIA GeForce RTX 4080, proprietary driver 595.91.07
• Adapter: Steam Frame Wireless Adapter (28de:2432), in-tree rtw89_8852cu, firmware 0.27.125.0, USB 3 link at 5000M (behind a motherboard hub)
• Title: Half-Life: Alyx (appid 546560), native Linux, so no Proton in the path

Session 2026-09-26 23:41:38 → 23:51:50 (10.2 min of gameplay)

• 458 Reset video stream lines in 61 bursts (~45/min, largest burst 21 resets)
• 103 Warning: Skipping ResetVideoStream because we have one pending.
• 1 ASSERT: "pFrame->ulVideoTimeline == ulTimelineSequence" at .../videovulkan.cpp:1643. at 23:46:04.631
• 14 Warning: retransmit request for unknown message N (frame number=N)

Bursts start cold — there is no host-side error preceding them, only an incoming reset request, and the acknowledged frame number freezes while the resets repeat:

23:45:33.094 Reset video stream because we had a stream reset request [wgpReset:113 != lastReset:112]
23:45:33.095 SVLFEC::ReportStreamReset() (m_iLastAcknowledgeFrameNumber = 37395)
23:45:33.117 Reset video stream because we had a stream reset request [wgpReset:117 != lastReset:113]
23:45:33.117 Warning: Skipping ResetVideoStream because we have one pending.
23:45:33.145 SVLFEC::ReportStreamReset() (m_iLastAcknowledgeFrameNumber = 37396)
23:45:33.280 SVLFEC::ReportStreamReset() (m_iLastAcknowledgeFrameNumber = 37412)
23:45:33.300 SVLFEC::ReportStreamReset() (m_iLastAcknowledgeFrameNumber = 37412)

Note wgpReset:117 != lastReset:113 — the reset counter jumps by 4, so reset requests are arriving coalesced or going missing.

Impact, measured by the compositor

Total.......... 54205 presents.  2485 dropped.  0 reprojected
Timed out. 32 total

4.6% dropped frames, matching the felt micro-stutters; the 32 timeouts are the moments video drops out entirely.

Confirming the link is not the cause

Per-second iw station dump and iw event for the whole session:

And not a host capacity limit

Encoder utilisation mean 23%, peak 31%; GPU mean 58%. Nothing is saturated.

The symptom profile differs from the original report

The original describes freezes of ~1–2 s every 20–60 s. What this host shows is more frequent and mostly much shorter — perceived as micro-stuttering rather than distinct freezes, with a handful of full dropouts on top.

Measured over the 61 bursts:

So the resets arrive roughly every 5 s rather than every 20–60 s, and most are sub-half-second. (Burst duration here means the span of reset requests; it is not necessarily a continuously frozen image, since frames do get through in between.)

Separately, adapter throughput collapsed from its normal 170–300 Mbit/s to below 20 Mbit/s on 7 distinct occasions, which is when video visibly dropped out entirely:

23:41:38   2 s, low 0.1 Mbit/s
23:42:24   7 s, low 9.4 Mbit/s
23:43:07   3 s, low 5.5 Mbit/s
23:43:35   1 s, low 16.8 Mbit/s
23:45:45   1 s, low 8.5 Mbit/s
23:49:50   1 s, low 2.9 Mbit/s
23:51:47   1 s, low 3.3 Mbit/s

Radio counters stay at 0 retries / 0 failed through all seven, so the PC simply stops sending.

One difference from the original report: no audio crackling

The audio path stays completely undisturbed here. Steam runs with -pipewire, and vrlink's PipeWire sink logs only 8 state changes in the whole session — all of them before gameplay started (23:39:11, 23:40:12, 23:41:35) or after it ended (23:51:50 onward). During the 10.2 minutes containing all 61 reset bursts there is not a single SVLAudioPipewire state change, and no audio artefacts were heard.

So on this host the video stream resets in isolation, while audio keeps streaming through the bursts. If the audio crackling in the original report is consistent, that may be a second symptom rather than part of the same failure — which would narrow this to the video encode path alone.

On the multi-interface theory from #962

In this session vrlink bound to only two addresses — the adapter link and a link-local IPv6 — and Found primary link FRAME_SUBNET.26 held throughout, with 0 Mbit/s on every other interface. Only 1 of 61 bursts falls within 3 s of a Received event indicating network change. (In an earlier session on the same host, with the LAN, a VPN and two docker bridges also up, vrlink bound to six addresses and the correlation was no better: 1 of 21.) On this host that mechanism does not explain the bursts.

Wi-Fi power save was enabled on the adapter, and disabling it measurably reduces the bursts

Everything was at its defaults for the session above; none of the workarounds from the original report were applied. It turns out that on this distribution "default" means power save enabled on the streaming radio:

• Debian/Ubuntu/Mint ship /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf with wifi.powersave = 3 (enabled).
• The Steam-managed connection profile for the adapter has 802-11-wireless.powersave: 0 (default), which falls through to that global value.
• Result: iw dev <adapter> get power_save → Power save: on, on the interface carrying the video stream.

Arch, where the original report comes from, does not ship that conf.d drop-in, so power save is off there by default. That may explain why the symptom profile differs.

I repeated the same title on the same host about an hour later with power save disabled. Everything else identical — same SteamVR instance, same adapter, same room:

Every metric moves the same way — roughly 18% fewer resets, shorter bursts, longer gaps between them, and fewer dropouts. This is one session against one session, so I would call it a consistent signal rather than a proven effect, but the direction is unambiguous and the stutter was noticeably milder.

It does not fix the problem: the bursts continue at a similar character, which is consistent with power save being an aggravating factor on the return path (reset requests and acknowledgements reaching the host) rather than the cause.

One practical note: setting 802-11-wireless.powersave 2 on the Steam-managed profile does not survive. On the next connection the value was back to 0 (default) — the profile appears to be rewritten when Steam brings the adapter up, so the setting has to be applied with iw on the live interface each session. If power save does aggravate this, having Steam write powersave=2 into the profile it manages would help every user on a Debian-derived distribution.

Capture tooling and the full anonymized per-second timeline (radio, throughput, GPU, processes, all SteamVR logs merged) are available on request.

System

• GPU: AMD Radeon 8060S Graphics (Strix Halo APU, integrated), RADV, Mesa 26.2.3 (Fedora mesa-vulkan-drivers-freeworld)
• CPU/APU: AMD Ryzen AI Max ("Strix Halo")
• OS: Fedora Linux 44 KDE Plasma, kernel 7.2.7-200.fc44.x86_64, Wayland
• SteamVR: 2.17.10 stable; Steam client 1788652215
• Headset: Steam Frame, over the included wireless adapter (Realtek RTL8852CU, in-tree rtw89_8852cu, USB 3)
• Title: Half-Life: Alyx (appid 546560), native Linux (no Proton in the path)
• Codec: HEVC over Vulkan Video (VK_KHR_video_encode_h265), slice count: 4

Session (~8 min at 50% render resolution, 2157×2157/eye)

• 193 Reset video stream because we had a stream reset request lines, in bursts — peak 128 in a single minute (08:56)
• 126 Warning: Skipping ResetVideoStream because we have one pending.
• 5× ASSERT: "pFrame->ulVideoTimeline == ulTimelineSequence" at .../videovulkan.cpp:1643.
• Compositor: Total dropped frames: 844 then 476, 0 reprojected (drops show as raw judder); repeated WaitForAcquire timed out (FAILED) storms (2697 / 2695 messages suppressed per 30 s window)

Bursts start cold with an incoming reset request, and the acknowledged frame number freezes while resets repeat — same as the other reports:

08:56:00.402 vrlink: Reset video stream because we had a stream reset request [wgpReset:23 != lastReset:22]
08:56:00.402 vrlink: SVLFEC::ReportStreamReset() (m_iLastAcknowledgeFrameNumber = 6086)
08:56:00.406 vrlink: [VideoVulkan] Bitstream header size: 87
08:56:00.420 vrlink: Reset video stream because we had a stream reset request [wgpReset:25 != lastReset:23]
08:56:00.420 vrlink: SVLFEC::ReportStreamReset() (m_iLastAcknowledgeFrameNumber = 6087)
08:56:00.428 vrlink: [VideoVulkan] Bitstream header size: 87
08:56:00.571 vrlink: Reset video stream because we had a stream reset request [wgpReset:26 != lastReset:25]
...
08:56:16.892 vrlink: ASSERT: "pFrame->ulVideoTimeline == ulTimelineSequence" at /data/src/vrlink/driver_vrlink/videovulkan.cpp:1643.

The wireless link is healthy. A iw dev wlan0 station dump during the session showed 0 tx retries, 0 tx failed, signal -63 dBm, 6 GHz channel 37, 160 MHz, HE (Wi-Fi 6E) rates rx ~1921 / tx ~1102 Mbit/s. (I sampled once rather than per-second across a freeze like others did, but there were no retries/failures and no scans/disconnects.)

Two extra notes:

1. Load-independent. I hit this at full auto resolution (3738×3738/eye) and again after dropping SteamVR render resolution to 50% (2157×2157/eye). The GPU-side dropped-frame rate fell (≈7.6% → ≈2.7%), but the reset-storm rate did not — same bursts, still 128/min. So it isn't the APU falling behind; it's the encode/stream path.
2. Fedora-specific prerequisite (for other Fedora users landing here): you get no video at all until you install the freeworld Mesa Vulkan driver — stock Fedora mesa-vulkan-drivers ships without VK_KHR_video_encode_h264/h265 (only royalty-free AV1 encode), so the Frame's HEVC encoder can't initialize. sudo dnf swap mesa-vulkan-drivers mesa-vulkan-drivers-freeworld (and the .i686) fixes the no-video case; the reset storm above is what remains after that.

Full vrserver.txt / driver_vrlink.txt available on request.

System

• OS: Pop!_OS 24.04 LTS, kernel 7.1.9-x64v3-xanmod1, Wayland, COSMIC desktop
• GPU / driver: NVIDIA GeForce RTX 5070, driver 595.84
• Steam client: 1782866176
• SteamVR: 2.18.1 beta (build 1790102919)
• Headset: Steam Frame
• Adapter: Steam Frame Wireless Adapter
• Codec: HEVC over Vulkan Video ([VideoVulkan], slice count 4)
• Title: VRChat (native, streamed from headset)

vrlink settings already in place (nothing exotic)

driver_vrlink: streamFormatWidth 640, targetBandwidth 30
steamvr: preferredRefreshRate 72, disableAsync true

So this is not high-bitrate / high-res / reprojection. The storm happens anyway.

What the logs show (single ~4.7 min session, 18:25:21–18:30:00)

• 601 Reset video stream because we had a stream reset request [wgpReset:N != lastReset:M] in vrserver.txt (~129/min)
• 224 Warning: Skipping ResetVideoStream because we have one pending.
• 381 [VideoVulkan] Created vkCreateVideoSessionParametersKHR (encoder session rebuilt on nearly every reset)
• wgpReset counter reached 859; it jumps by >1 between lines (coalesced/missing requests), same as other reports
• 0 ulVideoTimeline == ulTimelineSequence assertions this session (intermittent — seen in other sessions)

Excerpt:

18:26:56.470 [VideoVulkan] Bitstream header size: 87
18:26:56.485 Reset video stream because we had a stream reset request [wgpReset:183 != lastReset:182]
18:26:56.788 [VideoVulkan] CreateVideoSessionParamaters: slice count: 4
18:26:57.252 Reset video stream because we had a stream reset request [wgpReset:186 != lastReset:185]
18:27:07.559 Reset video stream because we had a stream reset request [wgpReset:201 != lastReset:200]

Symptom
Headset tracks head + both controllers and controller input works fine in-game, but video micro-stutters/freezes constantly — unplayable. Felt as frequent judder and 1–2 s freezes. A different (older) SteamVR build did not stutter on the same host/adapter, but then controllers don't work for the frame.

Possibly relevant

• vrlink: OpenSSL Soft (Old) AES PERF: 82.440231 MByte/s — software AES at ~82 MB/s (see @lixsldotnet's note about vrlink failing to load OpenSSL and falling back to soft AES; low throughput here too, though they found the resets persisted after fixing it).

Steps to reproduce

1. SteamVR 2.18.1 beta on the host above, Steam started with -pipewire -vrlinkforceenable, SteamVR started manually first.
2. Connect Steam Frame over the Wireless Adapter.
3. Launch VRChat from the headset.
4. Video resets continuously

1. The patch. Against v7.3-rc4, drivers/net/wireless/realtek/rtw89/regd.c. If the hunks do not apply to your kernel, the two blocks are easy to place by hand in rtw89_reg_6ghz_power_recalc().

@@ -1129,6 +1129,14 @@ static bool __rtw89_reg_6ghz_power_recalc(struct rtw89_dev *rtwdev)
 	return true;
 }
 
+/* Explicit 6 GHz power class for the Steam Frame adapter (28de:2432).
+ * 0 = follow the AP (default), 1 = VLP, 2 = LPI, 3 = SP.
+ */
+static int reg6_pwr_override;
+module_param(reg6_pwr_override, int, 0644);
+MODULE_PARM_DESC(reg6_pwr_override, "6 GHz power class override: 0 follow AP, 1 VLP, 2 LPI, 3 SP");
+
 static int rtw89_reg_6ghz_power_recalc(struct rtw89_dev *rtwdev,
 				       struct rtw89_vif_link *rtwvif_link, bool active,
 				       unsigned int *changed)
@@ -1171,6 +1179,13 @@ static int rtw89_reg_6ghz_power_recalc(struct rtw89_dev *rtwdev,
 
 	rcu_read_unlock();
 
+	if (active && reg6_pwr_override >= 1 && reg6_pwr_override <= 3) {
+		rtwvif_link->reg_6ghz_power = reg6_pwr_override - 1;
+		dflt = false;
+		rtw89_info(rtwdev, "6 GHz power class forced to %d by reg6_pwr_override\n",
+			   rtwvif_link->reg_6ghz_power);
+	}
+
 	if (!dflt && blocked[rtwvif_link->reg_6ghz_power]) {

Build against the source of your running kernel and install next to the stock modules:

cd <kernel source for $(uname -r)>/drivers/net/wireless/realtek/rtw89
make -C /lib/modules/$(uname -r)/build M=$PWD modules   # add LLVM=1 on clang-built kernels (CachyOS)
sudo mkdir -p /lib/modules/$(uname -r)/updates/rtw89
sudo cp rtw89_core.ko rtw89_usb.ko rtw89_8852c.ko rtw89_8852cu.ko /lib/modules/$(uname -r)/updates/rtw89/
sudo depmod -a
echo 'options rtw89_core reg6_pwr_override=2' | sudo tee /etc/modprobe.d/rtw89-frame.conf

Reboot or replug the adapter (a plain module reload can leave it rfkilled). It took effect when dmesg shows 6 GHz power class forced to 1 by reg6_pwr_override and txpwr_table shows [reg6_pwr_type] 1. Rebuild after every kernel update. LPI is the indoor class; it is allowed indoors in the EU, the US and Canada as far as I know. A patched morrownr/rtw89 like @WBosonic used does the same job.

@Lewin225 could you post your txpwr_table with the headset connected? Your 0.22 % loss between adapter and headset is exactly what I measured on the stock driver.

2. The power fix is necessary, not sufficient. @WBosonic is right that it is not only the network. Each of these was measured to matter here:

• Resizable BAR. With a 256 MiB BAR, heavy titles ran in slow motion and froze while the GPU sat idle: every amdgpu command submission spent 14 to 34 ms in the kernel's VRAM allocator. So changing that BIOS setting fixed a lot for me, although its maybe not relevant for this specific thread like the other poitns. Check sudo dmesg | grep BAR=; if it says 256M, turn both BIOS options on. @WBosonic

"Beat Saber hangs once a minute, Alyx unplayable" on a 9070 XT is exactly what it looked like here, so this is the first thing I would check.

• driver_vrlink.forceBaselineVideoFEC true in steamvr.vrsettings: removed the aborts that were left after the power fix.
• The headset's home Wi-Fi. Its own scans share the radio with the 6 GHz hotspot; one scan cost 2000+ stream aborts here. For the test, remove the home network from the headset (or at least set driver_vrlink.allowMultipleLinks false).
• Kernel 7.3 if the adapter is on a chipset USB port. Before 7.3 every 2.4 GHz scan could crash the adapter (rtw89_hw_scan_offload failed ret -110 and a firmware reload, as @Postmortals saw); 7.3 drops that band for this adapter. Switching to iwd avoids the same scans from the other side.
• SteamVR 2.18.2 beta on AMD (public 2.17.10 still has the right-eye jitter) and bandwidth on automatic for the test.

3. Not on the adapter? @miversen33 @APTX over home Wi-Fi the rtw89 patch does nothing for you, since the router is the transmitter then. What remains there is the vrlink side from my first comment: a 20 to 50 ms stall becomes a reset storm instead of being absorbed like on Windows (@bushibot's Pico 4 report is the same thing). That part only Valve can fix. The BAR check and the headset scanning still apply.

4. If you still get storms with 1 and 2 in place, this is what would let us tell the adapter, the GPU and vrlink apart:

• uname -r, GPU and driver version, SteamVR version and branch, Frame OS version, the game
• sudo dmesg | grep -E "BAR=|reg6_pwr_override"
• sudo cat /sys/kernel/debug/ieee80211/phy*/rtw89/txpwr_table while the headset is connected (the [reg6_pwr_type] line and the [TX power limit] block)
• sudo dmesg | grep rtw89 after the session (firmware resets, scan failures)
• whether the headset had its home Wi-Fi on, and the driver_vrlink section of ~/.steam/steam/config/steamvr.vrsettings
• grep -c "stream reset request" ~/.steam/steam/logs/vrserver.txt together with the play time
• the full vrserver.txt, vrcompositor.txt and driver_vrlink.txt from ~/.steam/steam/logs/ for that session, as an attachment or gist

• The cap is real: the VLP default limits the dongle (+5 dB at the Frame when forced to LPI, repeatable), and the Frame's hotspot configuration explains why it tops out at about 14 dBm EIRP.
• It matters, but only partly: forcing LPI reduced how often storms start by about 64%, and the Frame's direct error counts agree. It did not reduce how bad a storm gets once it starts, so total resets per minute were unchanged.
• What's left over is vrlink's recovery behaviour: a short backtrack window, a fixed 300 ms stuck timer, and the wedge after a link blip.

Pre Radio Patch

Setup: kernel 7.2.4-ogc3.1.fc44 (Bazzite 44, nvidia-open), RTX 3080 Ti (NVIDIA, so the
ReBAR/amdgpu point doesn't apply), dongle 28de:2432 on rtw89_8852cu fw 0.27.129.4,
USB 3 port on the CPU-integrated controller (not chipset), Frame OS 0.4.3,
SteamVR . No rtw89 scan or firmware errors in the kernel log.

• The Frame's beacon, read from the dongle's scan cache (iw scan dump), has
  "6 GHz Operation Information: 0x2513272f06 ... Regulatory Info: 2" (VLP), ch 37,
  160 MHz. iw reports the dongle at 23 dBm, but that is only the regulatory cap.
• Indirect power check: the Frame hears the dongle's ACKs at a median of -52 to -64 dBm
  while the dongle hears the Frame at -47 to -57. That is a 5 to 13 dB asymmetry
  (median about 7.5 dB) with the Frame's wlanap at 5 dBm. Not conclusive on its own,
  but consistent with a lower-power dongle. I'd expect it to shrink by about 9 dB with
  the patch.
• Loss: over one 640 s session the PC sent ~9.74M UDP datagrams and the Frame's UDP
  layer received ~9.69M, about 0.5% (rough; includes any unrelated PC UDP). No drops
  in the PC send buffer, mac80211 queue (drops 0), the Frame's receive path or its
  UDP buffer, and ping showed 0% loss. So the loss happens between the PC's send and
  the Frame's radio.
• forceBaselineVideoFEC true: "too many packets missing" aborts on the Frame fell
  from 4.1/min to 0.1/min at 100 Mbit/s.
• Bitrate: 0 resets/min at 25 Mbit/s, 2 to 3/min at 100 (one session 14.6/min),
  about 37/min at the default.
• allowMultipleLinks is already false. The Frame's home Wi-Fi is still on (by design).

Results so far with the patch (added 2026-10-03)

• Patch loaded via insmod (stock rtw89 replaced, not persistent). dmesg: "6 GHz power class forced to 1 by
  reg6_pwr_override" printed at each association.
• Same-position A/B (ab-power.sh, override 0 = follow AP/VLP vs 2 = forced LPI, headset still, 30 s each):
  VLP: Frame hears dongle -57 dBm, dongle hears Frame -50 -> asymmetry -7.0 dB
  LPI: Frame hears dongle -52 dBm, dongle hears Frame -50 -> asymmetry -2.0 dB
  => LPI minus VLP = +5.0 dB (one pair only; dongle-side reading unchanged, so position was steady).
  A 4 -> 13 dBm per-chain change would predict about +9 dB; the AP's Transmit Power Envelope may be
  capping it (not decoded yet).
• Stream (run 9, 8.7 min, 100 Mbit/s, FEC, LPI active): 7.4 resets/min, within the unpatched range of 2.3 to
  14.6/min for the same settings, so no clear stream improvement. Whole-run asymmetry was -5.0 dB (same as
  unpatched run 6), so the asymmetry during play is dominated by position/body effects.
• Run-to-run variance is large, so a stream comparison needs several alternating runs.

A/B repeated (added 2026-10-03, ab-power.sh with Frame-side deauth, headset still, 30 s per setting)

LPI minus VLP = +5.0 dB, repeated across three separate windows each way; the dongle-side reading was
constant so position was steady. "power class forced" logged once per LPI association, never for VLP.
Some windows gave no samples (ssh to the Frame failed right after re-association), 4 of 8 valid.

Why +5 and not +9: the Frame's hostapd config (/var/run/softap_hostapd.conf) has he_6ghz_reg_pwr_type=2
(VLP), reg_def_cli_eirp=28 (0.5 dB units, so about 14 dBm EIRP; unit not confirmed) and reg_def_cli_eirp_psd=22.
rtw89 applies the AP's Transmit Power Envelope on top of the power class, so forcing LPI cannot exceed that.
Stock VLP in rtw89 gives about 4 dBm per chain (about 7 dBm total) while the VLP limit is 14 dBm EIRP, so the
driver's VLP tables look conservative; Windows uses the chip maximum (16/13 dBm).

Interleaved blinded test, pooled (2 sessions, 6 pairs, added 2026-10-03; runs 20261003-205515 + 20261003-221850)

Setup: Beat Saber, 100 Mbit/s, FEC on, headset worn; override 0 (VLP, stock) vs 2 (forced LPI) flipped every 180 s,
random order within each pair, blind, Frame-side deauth at each switch, first 20 s of each block ignored.
Kernel log confirms "power class forced" in every LPI block and none in VLP blocks.

Reading: forcing LPI (+5 dB at the Frame, same-position A/B) cut how often storms START (about 64% fewer) but not
how severe they are once started: a few giant cascades (67 and 27 resets in single LPI blocks) dominate the reset
count, 8.4 resets/storm on LPI vs 3.2 on VLP. That matches the comment's "necessary, not sufficient": vrlink's
recovery is the amplifier.
Caveats: storms/min was chosen after seeing that resets/min did not separate (post hoc; 4 metrics tested);
one player, one game, 6 pairs; per-block resets/min ranged 0.4 to 25.2 on both settings. The Frame-side RSSI
sampling died at the first switch in session 2, so the power check there rests on the kernel log only.

Pushing the dongle to LPI get's it up to 14dBm, which is where it should be on VLP. but after that it's capped by the headset itself asking for VLP correctly. The headset being VLP is correct for something that goes outdoors, but if it could be set to LPI the link should get up to 16dbm (I think... dongle chip's maximum is 16 dBm?)

The frame's hotspot class comes from the Frame's softapmanager, which writes /var/run/softap_hostapd.conf with he_6ghz_reg_pwr_type=2 (VLP) and reg_def_cli_eirp=28 (14 dBm). LPI would mean type 0 and a higher client limit

But it wouldn't stick. That file is regenerated each time the hotspot starts. Might require altering SteamOS for only +2dbm gain and that's only for frame->dongle returns.. just tracking data, no bonus to video

Also. This isn't the real issue this thread is about, when packets are lost the storms still happen, they're just lost less often

Every session on my machine logs this when the adapter connects (in Steam's connection_log.txt / console output):

CRemoteClientDongle: No holo-realtek-firmware-toggles helper script found, low latency mode unavailable

On SteamOS, Steam calls /usr/bin/holo-polkit-helpers/holo-realtek-firmware-toggles set-low-latency-mode on on connect. That helper only ships in SteamOS. The source is public, in holo-main holo-realtek-firmware-toggles 1.3-3. In low latency mode it changes these settings through rtw89 debugfs:

• aggressive EDCA on all four queues: TXOP 2000 µs, CWmax 7, CWmin 3, AIFSN 1, written to c300/c304/c308/c30c. The script's comment says these are kept "roughly inline with what Steam manually sets on Windows".
• firmware HW_SCAN and INACTIVE_PS off (disable_dm)
• A-MSDU off, power save off
• HE-MCS capped at 0–9, static packet-detection threshold −75 dBm

Setup: NixOS, kernel 7.2.0, RX 9070 XT (RADV), SteamVR 2.18.2 beta, Frame OS 0.4.3, Steam Frame Wireless Adapter on 6 GHz ch 37 / 160 MHz, regdom NL. Already in place: @Molier's reg6_pwr_override=2 (confirmed [reg6_pwr_type] 1), forceBaselineVideoFEC, automatic bandwidth, allowMultipleLinks false, home Wi‑Fi off on the headset, power save off.

Result in Half-Life: Alyx, about 5 minutes each:

The TX-power patch alone did not measurably change the reset rate here. That was 132–289 resets/min over two sessions. Low latency mode on top of it is what made it playable.

I left out two steps. I skipped the static −75 dBm PD threshold because @Molier reported it made the adapter deaf on fades. I skipped the HE-MCS cap because iw set bitrates reportedly oopsed the driver on a 7.3-rc kernel (#946).

Important: the EDCA registers get cleared again, not only on reassociation. In one session they were reset to 0 when the stream session restarted, while the adapter stayed associated the whole time. A one-shot hook on connect isn't enough, so I re-check every 5 s. This needs CONFIG_RTW89_DEBUGFS=y, which many distro kernels don't enable, and debugfs writes are blocked under Secure Boot lockdown.

#!/bin/bash
edca="003F3219"   # TXOP 2000us, CWmax 7, CWmin 3, AIFSN 1 (same encoding as the holo helper)
while sleep 5; do
  for dev in /sys/class/net/*; do
    [[ "$(cat "$dev/device/../idVendor" 2>/dev/null)" == 28de && "$(cat "$dev/device/../idProduct" 2>/dev/null)" == 2432 ]] && break
    dev=""
  done
  [[ -n "$dev" ]] || continue
  iface=$(basename "$dev")
  [[ "$(iw dev "$iface" link)" == Connected* ]] || continue
  d="/sys/kernel/debug/ieee80211/$(basename "$(readlink -f "$dev/phy80211")")/rtw89"
  echo "c300 4" > "$d/read_reg"
  [[ "$(grep -o '0x[0-9a-f]*$' "$d/read_reg")" == "0x${edca,,}" ]] && continue
  echo 0x30 > "$d/disable_dm"                       # HW_SCAN | INACTIVE_PS off
  iw dev "$iface" set power_save off
  iw dev "$iface" set tidconf tids 0xff amsdu off
  for r in c300 c304 c308 c30c; do echo "$r $edca 4" > "$d/write_reg"; done
  echo "applied low latency mode on $iface"
done

What's left: a scene change (an Alyx health station, in my case) can still start a reset storm that vrlink never recovers from. The stream stops and the PC logs Connection inactive for 30 seconds. That looks like the vrlink recovery issue others described.

Request for Valve: could Steam ship this helper, or an equivalent, on desktop Linux? Or at least apply the EDCA values itself, the way it does on Windows?

System:

• CachyOS / kernel 7.2.8-cachyos
• Ryzen 7 9800X3D
• NVIDIA RTX 5090
• NVIDIA 615.71.09
• SteamVR 2.17.10 stable
• Steam Frame

I see the same Reset video stream because we had a stream reset request / SVLFEC::ReportStreamReset() bursts and 1–2 second freezes.

I specifically tested the network path in three configurations:

1. Multi-Link enabled
2. Steam Frame wireless adapter only
3. Normal 5 GHz Wi-Fi only, with the Frame dongle physically unplugged

The reset storms occur in all three configurations.

With dongle-only I saw an especially large burst where wgpReset increased from roughly 789 to >900 in about two seconds, while the acknowledged frame number stopped progressing.

With the dongle completely removed and the Frame connected through a FRITZ!Box 7530 AX over 5 GHz Wi-Fi 6, I still get repeated reset bursts and eventually Connection inactive.

So in my case this is definitely not specific to the Steam Frame dongle, 6 GHz, or Multi-Link.

I also checked the kernel logs around the failures and did not see NVIDIA Xid errors, GPU resets, USB resets, or other obvious kernel-level faults.

One additional symptom I saw once after a disconnect was:

797:
Assertion Failed in function GetBitRange():
*pEnd > *pStart

GetBitRange(4040 -> 4040)
end is before or same as start

I cannot prove that this assertion has the same root cause as the reset storms, and it does not appear in my normal host-side SteamVR logs, but I wanted to mention it in case it is useful.

One other possibly unrelated finding:

Soft AES PERF: ~30 MB/s
OpenSSL EVP (New) AES PERF: 0 MB/s
OpenSSL Soft (Old) AES PERF: 0 MB/s

So VRLink appears to be falling back to its software AES implementation on my setup as well.

Happy to provide full vrserver.txt / driver_vrlink.txt logs or run additional tests if useful.

Setup: RTX 3090 (NVIDIA 615.71.09), Arch / KDE Plasma Wayland, kernel 7.2.6-arch2-1 (CONFIG_RTW89_DEBUGFS is enabled on Arch), Steam Frame Wireless Adapter (28de:2432, rtw89_8852cu), regdomain CA, SteamVR [SteamVR version], Frame OS [Frame OS version], Half-Life: Alyx. Resizable BAR is off on this machine (BAR1 = 256 MiB).

1. TX power patch on 7.2.6

The hunks don't apply as-is on 7.2.6, but the two blocks go in the same places by hand: the module_param block right before rtw89_reg_6ghz_power_recalc(), and the override block right after its rcu_read_unlock(), before if (!dflt && blocked[...]). Built against the kernel headers, installed in updates/, options rtw89_core reg6_pwr_override=2. Confirmed with 6 GHz power class forced to 1 by reg6_pwr_override in dmesg.

TX power limits with the IC (Canada) table, ch 47, 160 MHz:

Note that the IC table still caps LPI well below the 13–16 dBm reported with ETSI, so users in Canada (and maybe other non-ETSI regions) get less out of the patch.

2. Results, step by step

Resets per minute = Reset video stream count between the first and last reset of each session. Single sessions of ~13–22 min each, so treat small differences as noise.

The low latency script (EDCA registers, disable_dm 0x30, power save and A-MSDU off) made the biggest single difference here too, confirming @RalfN's request: Steam should apply these settings on desktop Linux like it does on SteamOS and Windows. Without them, the desktop Linux experience is far worse than it needs to be.

Settings during the final session: allowMultipleLinks false, forceBaselineVideoFEC true, automaticBandwidth true. The headset's home Wi-Fi stayed on: in my setup the headset would not connect to the adapter without it, so I could not test that variable.

3. Unrelated issues found along the way (may help others)

• Steam library on NTFS: with the native build on an ntfs3 partition, the game crashed after a few minutes with serializedentity.h (797): Assertion Failed in function GetBitRange(), even with a new game. After moving the game to btrfs, that crash was gone.
• Native build instability: after the move, the native build still crashed once with a SIGSEGV in libscenesystem.so (worker thread, no driver frames in the stack), and the audio crackling came and went. Under Proton Experimental: no crash in two sessions (~19 and ~13 min) and no crackling at all.
• steamwebhelper aborted (SIGABRT) at the end of several sessions; no effect on the game.

4. Still vrlink's

With all of the above, a few resets remain, and the Windows client on the same hardware has none. As @Molier and @bushibot's Pico 4 report show, a short stall can still trigger a reset loop in Linux vrlink that the Windows client absorbs. That part still needs a fix from Valve.

Tested on 7.2.6-arch2-1 with an RTX 3090. Run everything as your normal user; sudo is used where needed.

0. Prerequisites check

cat /sys/kernel/security/lockdown        # must show [none], otherwise debugfs writes are blocked
ls /sys/kernel/debug/ieee80211/          # needs CONFIG_RTW89_DEBUGFS (enabled on Arch)
sudo pacman -S --needed base-devel linux-headers

1. Get the rtw89 source matching your running kernel

V=$(uname -r | sed 's/-arch.*//')        # e.g. 7.2.6
cd ~
curl -LO https://cdn.kernel.org/pub/linux/kernel/v${V%%.*}.x/linux-$V.tar.xz
tar -xf linux-$V.tar.xz linux-$V/drivers/net/wireless/realtek/rtw89
cd linux-$V/drivers/net/wireless/realtek/rtw89

2. Apply @Molier's TX power override patch

cat > /tmp/rtw89-reg6.patch << 'EOF'
--- regd.c.orig
+++ regd.c
@@ -1129,6 +1129,13 @@
 	return true;
 }
 
+/* Explicit 6 GHz power class for the Steam Frame adapter (28de:2432).
+ * 0 = follow the AP (default), 1 = VLP, 2 = LPI, 3 = SP.
+ */
+static int reg6_pwr_override;
+module_param(reg6_pwr_override, int, 0644);
+MODULE_PARM_DESC(reg6_pwr_override, "6 GHz power class override: 0 follow AP, 1 VLP, 2 LPI, 3 SP");
+
 static int rtw89_reg_6ghz_power_recalc(struct rtw89_dev *rtwdev,
 				       struct rtw89_vif_link *rtwvif_link, bool active,
 				       unsigned int *changed)
@@ -1171,6 +1178,13 @@
 
 	rcu_read_unlock();
 
+	if (active && reg6_pwr_override >= 1 && reg6_pwr_override <= 3) {
+		rtwvif_link->reg_6ghz_power = reg6_pwr_override - 1;
+		dflt = false;
+		rtw89_info(rtwdev, "6 GHz power class forced to %d by reg6_pwr_override\n",
+			   rtwvif_link->reg_6ghz_power);
+	}
+
 	if (!dflt && blocked[rtwvif_link->reg_6ghz_power]) {
 		rtw89_debug(rtwdev, RTW89_DBG_REGD,
 			    "%c%c 6 GHz power type-%u is blocked by policy\n",
EOF
cp regd.c regd.c.orig
patch -l regd.c < /tmp/rtw89-reg6.patch
diff -u regd.c.orig regd.c               # should show exactly the two added blocks

If patch rejects a hunk on your kernel version, place the two blocks by hand: the first right before static int rtw89_reg_6ghz_power_recalc(, the second right after the rcu_read_unlock(); that precedes if (!dflt && blocked[...]).

3. Build and install next to the stock modules

make -C /lib/modules/$(uname -r)/build M=$PWD modules -j$(nproc)
sudo mkdir -p /lib/modules/$(uname -r)/updates/rtw89
sudo cp rtw89_core.ko rtw89_usb.ko rtw89_8852c.ko rtw89_8852cu.ko /lib/modules/$(uname -r)/updates/rtw89/
sudo depmod -a
echo 'options rtw89_core reg6_pwr_override=2' | sudo tee /etc/modprobe.d/rtw89-frame.conf
modinfo -n rtw89_core                    # must point to .../updates/rtw89/rtw89_core.ko

A pahole version differs warning during the build is harmless.

4. Reboot (replugging the adapter is not enough if rtw89_core is already loaded), then verify:

cat /sys/module/rtw89_core/parameters/reg6_pwr_override     # 2

With the headset connected through the adapter:

sudo dmesg | grep reg6_pwr_override      # "6 GHz power class forced to 1"
IF=$(iw dev | awk '/Interface wlp/{print $2}' | while read i; do [ "$(cat /sys/class/net/$i/device/../idProduct 2>/dev/null)" = 2432 ] && echo $i; done)
PHY=$(cat /sys/class/net/$IF/phy80211/name)
sudo grep -E "reg6_pwr_type|OFDM_2TX|MCS_2TX_160M" /sys/kernel/debug/ieee80211/$PHY/rtw89/txpwr_table   # [reg6_pwr_type] 1

Note: run sudo grep with $PHY rather than phy*. Your user can't read debugfs, so the shell can't expand the glob.

5. SteamVR settings

With SteamVR closed, edit ~/.local/share/Steam/config/steamvr.vrsettings so the driver_vrlink section contains:

"driver_vrlink" : {
   "allowMultipleLinks" : false,
   "automaticBandwidth" : true,
   "forceBaselineVideoFEC" : true
},

Keep any other keys already in that section, and validate the JSON before starting SteamVR:

python -m json.tool ~/.local/share/Steam/config/steamvr.vrsettings > /dev/null && echo OK

6. @RalfN's low latency script (only change: a timestamp in the log line)

cat > ~/frame-lowlatency.sh << 'EOF'
#!/bin/bash
edca="003F3219"   # TXOP 2000us, CWmax 7, CWmin 3, AIFSN 1 (same encoding as the holo helper)
while sleep 5; do
  for dev in /sys/class/net/*; do
    [[ "$(cat "$dev/device/../idVendor" 2>/dev/null)" == 28de && "$(cat "$dev/device/../idProduct" 2>/dev/null)" == 2432 ]] && break
    dev=""
  done
  [[ -n "$dev" ]] || continue
  iface=$(basename "$dev")
  [[ "$(iw dev "$iface" link)" == Connected* ]] || continue
  d="/sys/kernel/debug/ieee80211/$(basename "$(readlink -f "$dev/phy80211")")/rtw89"
  echo "c300 4" > "$d/read_reg"
  [[ "$(grep -o '0x[0-9a-f]*$' "$d/read_reg")" == "0x${edca,,}" ]] && continue
  echo 0x30 > "$d/disable_dm"                       # HW_SCAN | INACTIVE_PS off
  iw dev "$iface" set power_save off
  iw dev "$iface" set tidconf tids 0xff amsdu off
  for r in c300 c304 c308 c30c; do echo "$r $edca 4" > "$d/write_reg"; done
  echo "$(date +%T) applied low latency mode on $iface"
done
EOF
chmod +x ~/frame-lowlatency.sh
sudo ~/frame-lowlatency.sh               # leave it running in a terminal during the VR session

It waits until the adapter is connected, then re-applies the settings whenever the registers get reset. Nothing is permanent: replugging the adapter or rebooting restores the defaults.

7. Game side

• Don't keep the Steam library on an NTFS partition (the native Half-Life: Alyx crashed with a GetBitRange assertion there). If Steam's "Move install folder" fails with "Content file locked", quit Steam and move it manually:

  steam -shutdown
  SRC=/path/to/NTFS/SteamLibrary/steamapps
  DST=~/.local/share/Steam/steamapps
  rsync -a --info=progress2 "$SRC/common/Half-Life Alyx" "$DST/common/"
  cp -a "$SRC/appmanifest_546560.acf" "$DST/"
  mv "$SRC/appmanifest_546560.acf" "$SRC/appmanifest_546560.acf.bak"

Then start Steam and verify the game files.

• Half-Life: Alyx was more stable under Proton Experimental than native here (no crashes, no audio crackling).

8. Measuring (optional)

# Before the session
D=$(LC_ALL=C date '+%b %d %Y'); T=$(date +%T)

# After the session, in the same terminal
LOGS=~/.local/share/Steam/logs
S(){ awk -v d="$D" -v t="$T" '($2" "$3" "$4)==d && $5>=t' $LOGS/vrserver.previous.txt $LOGS/vrserver.txt 2>/dev/null; }
echo "Resets : $(S | grep -c 'Reset video stream')"
echo "Asserts: $(S | grep -c 'ASSERT: "pFrame->ulVideoTimeline')"
S | grep "Reset video stream" | awk 'NR==1{print "First:", $5} END{print "Last:", $5}'

After every kernel update: the patched modules live under /lib/modules/<version>/updates/, so a new kernel silently falls back to the stock driver. Redo steps 1 to 4 with the new version.

To revert:

sudo rm -r /lib/modules/$(uname -r)/updates/rtw89 /etc/modprobe.d/rtw89-frame.conf
sudo depmod -a

Then reboot.

Summary of findings: the beta alone did not fix it. The TX power patch cut dropped frames from 28% to 4.9%, and the low latency script brought resets down to ~20/min. Multi-link made no clear difference either way. Two to three short bursts per minute remain even with both applied, and storms also occur over home Wi-Fi with the adapter out of the path.

Correction to my earlier comment: I cited "0 tx retries, 0 tx failed" as evidence of a healthy link. As @Molier pointed out, those counters aren't implemented for this USB driver, so that claim should be disregarded. They read 0/0 in every run below, including the worst.

System (unchanged except versions): AMD Radeon 8060S (Strix Halo APU), RADV / Mesa 26.2.3 freeworld, Fedora 44 KDE Wayland, kernel 7.2.8-200.fc44, SteamVR 2.18.2 beta (v1790893534), Steam client 1788652215. Steam Frame Wireless Adapter on rtw89_8852cu, USB 3 at 5000M behind two hubs, 6 GHz ch 37, regdomain US. Half-Life: Alyx native, 50% render resolution. The PC's onboard Wi-Fi (5 GHz, 40 MHz) is its only home network connection.

Results

Each run keeps everything from the row above it and adds one change. Counts are over the window where hlvr was running; dropped frames are from the compositor's Total ... presents / dropped line.

A "burst" is a run of Reset video stream because we had a stream reset request lines with no gap over 2 s.

What I take from it:

• The beta alone did not fix it here. The first three runs were unplayable; I stopped each after about 3 minutes.
• The TX power patch was the first change I could feel. Dropped frames fell from 28% to 4.9% and the adapter's PHY rate rose by about half. In the LPI run, 282 of the 387 resets were one burst 11 s before I quit; excluding it the rate is about 34/min.
• The low latency script took it to playable. Interruptions became brief enough that I mostly wasn't disoriented.
• Multi-link made no clear difference either way, with or without the other fixes. With it on, the full stream is duplicated over my home Wi-Fi (~130 Mbit/s on each interface).
• A residue of 2–3 bursts per minute remains in every low-latency run. Within the 14.6 min run, resets per minute ranged from 0 to 51, so storms cluster and short runs can mislead.

Caveats: one run per configuration, most of them short; the changes are stacked, not isolated; Alyx has no chapter select, so the runs were not on an identical segment; the low latency row changes power save and the EDCA/firmware settings together.

Accidental home Wi-Fi run

In one run with allowMultipleLinks false, vrlink logged Found primary link <home Wi-Fi address> two seconds before the adapter finished associating, and then stayed on home Wi-Fi for the whole session; the adapter carried nothing. Over 4.7 min at ~60 Mbit/s on 5 GHz: 24 resets/min, 4.3 bursts/min, 5.2% dropped. So the storms occur with the adapter out of the path, as others have reported.

This is also a small trap for anyone testing single-link: start SteamVR, wait for the adapter to associate, and only then start the stream, or you may be measuring your home network.

Low latency mode notes

The three lines above are what @RalfN's script (posted earlier in this thread) applies in a loop. Three things from running it here:

• With disable_dm 0x30 set, the driver rejects every scan (-EBUSY), so the flag has to be cleared while the adapter is disconnected. I made the loop write 0 to disable_dm whenever iw dev $IF link is not Connected; replugging the adapter also clears it.
• The SteamOS helper (1.3-3) does two more things these lines leave out: it caps HE-MCS at 0–9 and sets a static −75 dBm packet-detection threshold. Its reset writes 0x00 to disable_dm, which is the same clearing step as above.
• Unlike @RalfN, I did not see the EDCA registers get cleared mid-session: in each run they were written once and held.

Fedora notes

• Fedora's kernel has CONFIG_RTW89_DEBUGFS unset (same as Bazzite, per @Lewin225), so neither txpwr_table nor the low latency settings are available on the stock driver. I rebuilt the rtw89 modules from vanilla 7.2.8 source against kernel-devel, adding CONFIG_RTW89_DEBUG=y CONFIG_RTW89_DEBUGFS=y CFLAGS_MODULE="-DCONFIG_RTW89_DEBUG=1 -DCONFIG_RTW89_DEBUGFS=1" to the make line from @nix70900-bit's guide. The modules loaded against the Fedora kernel without complaint, and modprobe -r / modprobe picked them up without a reboot.
• @Molier's patch does not apply by line number on 7.2.8, but both blocks go in by hand exactly as @nix70900-bit described.
• Wi-Fi power save was on by default on the adapter here too, on the Steam-managed profile.
• The software-AES fallback others mentioned did not occur in these sessions (OpenSSL EVP (New) AES PERF: ~950–1400 MByte/s).

For Valve

Adding my voice to the two requests already made: apply the low-latency adapter settings on desktop Linux as on SteamOS and Windows, and the remaining bursts still look like vrlink turning short stalls into reset storms. Full vrserver.txt / vrcompositor.txt and per-second link captures for every run above are available on request.

Setup: Nobara 44 (CachyOS-based kernel 7.2.9-200.nobara.fc44), i9-10850K, RTX 4070 SUPER (NVIDIA 595.104.02), KDE Plasma Wayland, regdomain DE, SteamVR beta (build 25839986), Steam Frame Wireless Adapter (28de:2432, in-tree rtw89_8852cu) on USB 3, 6 GHz ch 37 / 160 MHz.

Host Reset video stream per minute in HL:Alyx:

With LPI the TX bitrate went from 650–860 Mbit/s (HE-MCS 5) to 1.3–2.4 Gbit/s (HE-MCS 7–11). Audio still stutters a bit while streaming.

Two pitfalls I hit, in case they help others:

1. disable_dm 0x30 (HW_SCAN off) breaks reconnecting. After the headset disconnected once, the adapter couldn't find the Frame AP again (NetworkManager activation failed with "network not found", the scan showed the SSID with channel 0 / signal 0). My version of the script writes 0 to disable_dm whenever there's no station, and sets it again after association. Reconnects work fine since.
2. After a warm reboot the adapter stays at USB 2 (480M). The chip keeps power, so the rtw89 USB 3 mode switch sees its own "already tried" marker in PAD_CTRL2 (MATCH_CNT) and skips the switch. Unplugging and replugging once brings it back to 5000M. Worth checking lsusb -t if your results look worse than expected.

Also, iw dev <if> link sometimes reported "Not connected" while the stream was running; iw dev <if> station dump was reliable for the connection check.

#!/bin/bash
# Low latency mode for the Steam Frame Wireless Adapter (28de:2432), modelled on SteamOS'
# holo-realtek-firmware-toggles (based on @RalfN's script in [#965](/issue/ValveSoftware/SteamVR-for-Linux/965)).
# Re-checks every 5 s because the EDCA registers get reset on stream restarts.
# Left out on purpose: static -75 dBm PD threshold and HE-MCS cap (issues reported in this thread).

edca="003f3219"   # TXOP 2000 us, CWmax 7, CWmin 3, AIFSN 1

while sleep 5; do
        iface=""
        for dev in /sys/class/net/*; do
                if [[ $(cat "$dev/device/../idVendor" 2>/dev/null) == 28de &&
                      $(cat "$dev/device/../idProduct" 2>/dev/null) == 2432 ]]; then
                        iface=$(basename "$dev")
                        break
                fi
        done
        [[ -n $iface ]] || continue

        d="/sys/kernel/debug/ieee80211/$(basename "$(readlink -f "/sys/class/net/$iface/phy80211")")/rtw89"
        [[ -d $d ]] || { echo "no rtw89 debugfs at $d"; continue; }

        # Not connected: re-enable firmware HW_SCAN. With HW_SCAN disabled the adapter
        # can't find the Frame on 6 GHz again after a disconnect (scan shows channel 0, signal 0).
        # 'iw link' sometimes says "Not connected" during a stream, so use station dump instead.
        if ! iw dev "$iface" station dump 2>/dev/null | grep -q '^Station'; then
                if ! grep -q 'Disabled DM: 0x0$' "$d/disable_dm"; then
                        echo 0 > "$d/disable_dm"
                        echo "not connected: re-enabled HW_SCAN on $iface"
                fi
                continue
        fi

        grep -q 'at 0x0000c300=' "$d/read_reg" || echo "c300 4" > "$d/read_reg"
        [[ $(grep -o '0x[0-9a-f]*$' "$d/read_reg") == "0x$edca" ]] && continue

        echo 0x30 > "$d/disable_dm"                      # firmware HW_SCAN + INACTIVE_PS off
        iw dev "$iface" set power_save off
        iw dev "$iface" set tidconf tids 0xff amsdu off
        for r in c300 c304 c308 c30c; do echo "$r $edca 4" > "$d/write_reg"; done
        echo "applied low latency mode on $iface"
done

Transparency note: I worked through the diagnosis, the driver build and this script together with Claude (Anthropic's AI assistant). The measurements are from my own sessions.

System:

• Distribution: openSUSE Tumbleweed, kernel 7.2.9-1-default
• GPU / driver: AMD Radeon RX 7800 XT, RADV (Mesa-26.2.4-1699.2.pm.2.x86_64)
• Desktop: KDE Plasma, X11
• SteamVR: 2.18.2 beta
• Wireless adapter: Steam Frame Wireless Adapter (Realtek RTL8852CU, USB ID 28de:2432), in-tree rtw89_8852cu driver, USB 3
• Regulatory domain: DE (6 GHz band available)
• Headset: Steam Frame, Multi-Link streaming disabled

Symptom: identical to the original report — the stream freezes for ~1–2 seconds while the game keeps
running on the PC (headset and inputs still tracked), audio crackles, then the stream re-establishes.
Occurs every few minutes during normal play (ITR1).

Already applied, no improvement of the resets:

• Wi-Fi power save disabled on the adapter (iw dev get power_save -> off)
• USB autosuspend disabled via udev rule for 28de:2432 (power/control = on)
• Multi-Link disabled, adapter in a USB 3 port with sightline to Steam Frame, system fully updated

Log evidence (vrserver.txt):
$ grep -c "Reset video stream" ~/.local/share/Steam/logs/vrserver.txt
1448

$ grep -m3 "ulVideoTimeline" ~/.local/share/Steam/logs/vrserver.txt
Sat Oct 10 2026 18:22:16.688272 [Info] - vrlink: ASSERT: "pFrame->ulVideoTimeline == ulTimelineSequence" at /data/src/vrlink/driver_vrlink/videovulkan.cpp:1685.
Sat Oct 10 2026 18:32:05.518147 [Info] - vrlink: ASSERT: "pFrame->ulVideoTimeline == ulTimelineSequence" at /data/src/vrlink/driver_vrlink/videovulkan.cpp:1685.

Same settings in both runs, 25 minutes apart: @Molier's reg6_pwr_override=2, @RalfN's low latency script, forceBaselineVideoFEC, multi-link on, Fedora 44, kernel 7.2.9, SteamVR beta v1791582248.

• Resets follow signal strength within a run too. In the desk run, seconds with the adapter at −55 dBm or stronger had 7 resets/min and seconds weaker than −60 dBm had 85–120. The elevated position kept the link above −55 dBm for 92% of the session, against 5% on the desk.
• Caveats: one run per position. The desk position also varies a lot between days (17 resets/min on 4 Oct at −59 dBm). The hub was removed at the same time as the move; a 3-minute check with the hub back in line at the elevated position showed the same signal and PHY rate, so the hub does not explain the radio difference.

Kernel 7.2.9: the patch applies to vanilla 7.2.9 regd.c, builds against Fedora's kernel-devel with the debugfs flags from my earlier comment, and logs 6 GHz power class forced to 1 by reg6_pwr_override. Modules installed under updates/ are per kernel: after the update to 7.2.9 I had no LPI and no debugfs for the low latency script until I rebuilt. A quick check is whether /sys/module/rtw89_core/parameters/reg6_pwr_override exists.

Correction: I wrote that I had not seen the EDCA registers get cleared mid-session. Today they were cleared once while the adapter stayed associated, and the script rewrote them at its next 5 s check, as @RalfN described.

Still open: in the good run the stream stopped once for about 10 s at −46 to −59 dBm, on both links at the same moment, with no reset requests beforehand. vrlink logged Connection inactive, the headset showed a "waiting" popup, and it recovered by itself. That looks like a separate problem from the reset storms.

Captures and logs for both runs are available on request.