A developer building a NATIVE OpenXR app for Valve’s Steam Frame has FILED one of the most carefully MEASURED bug REPORTS the headset has drawn so far. In issue #1020 on Valve’s SteamVR-for-Linux tracker, opened at 2:14 p.m. ET on October 16, the reporter says the Frame’s runtime OFFERS an app 90 Hz, ACCEPTS the request, RUNS at 90 Hz for roughly a TENTH of a second, and then DROPS to 72 Hz for the REST of the session without EVER telling the app.
FOUR hours later, at 6:32 p.m. ET, Valve posted SteamVR Beta 2.18.4. Its notes list THREE fixes, and NONE of them mentions REFRESH RATE. As of Sunday morning the issue had ZERO comments and NO Valve label.
What the Developer Logged
The app is a native ARM64 OpenXR title using Vulkan, launched either over ssh in Developer Mode or by Steam as a SteamOS Devkit Client title, NOT a Steam store app. It enables the XR_FB_display_refresh_rate extension and logs EVERY frame’s predicted display period and every runtime event. With the headset set to 90 Hz, the reporter DESCRIBES the SAME sequence at every session start:
- The runtime’s list of available rates contains ONE entry. In 30 of 53 logged sessions it was 90 Hz; in the other 23 it was 72 Hz, with NOTHING changed on the app side.
- When 90 Hz was listed, the request for 90 Hz RETURNED
XR_SUCCESS. - The first 1 to 13 frames arrived on an 11.111 ms period, which is 90 Hz. EVERY frame after that arrived on a 13.889 ms period, which is 72 Hz. The switch came 0.02 to 0.28 SECONDS after the session began, with NOBODY wearing the headset.
- Across about 1.17 MILLION logged frames, the app received NO refresh-rate-changed event. Measured over a whole session, the display ran at 71.999 Hz.
- In TWO sessions, the list of available rates CHANGED partway through, which the reporter notes the extension FORBIDS.
The reporter also says the app’s package carries a vrpreferences.json file asking for a MINIMUM of 90 Hz, in the format Valve documents for Steam Frame, and that RESTARTING the headset changed NOTHING. They add that they could NOT find the log line that would confirm the file was read, so that part is UNRESOLVED in their own account.
Why a Silent Drop Matters
The extension exists so an app can KNOW its display rate and PACE itself to it. This app streams video from a PC, so it told the PC to RENDER at 90 Hz. With the panel ACTUALLY at 72 Hz, FIVE frames arrive for every FOUR refreshes. The reporter measured the result in a worn session on October 8: moving objects JUMPED an extra 11 ms of motion about 18 times a SECOND. Their workaround is the one any developer would now need: IGNORE what the runtime PROMISES and either POLL the current rate or MEASURE the frame period directly.
That is a NARROW case today. The report covers ONE native devkit build, and it does NOT show the same behavior in Steam store titles or in PC VR streamed through SteamVR. But Valve is ACTIVELY courting STANDALONE and Android content on the headset, and a runtime that GRANTS a rate it does NOT deliver is exactly the kind of bug that surfaces later as UNEXPLAINED JUDDER in SOMEONE ELSE’S game.
What SteamVR 2.18.4 Actually Changes
Valve’s beta notes for 2.18.4 are SHORT. SteamVR gets a FIX for CRASHES at startup “with certain games” and a fix for an OCCASIONAL crash when unblocking previously blocked add-ons. Steam Link gets what Valve itself calls a “SPECULATIVE fix” for roughly 300 ms GAPS in frame delivery in some packet-loss situations. Valve NAMES no games and gives NO figures for how often those gaps occurred.
It is the FOURTH 2.18 beta in 23 DAYS, after 2.18.1 on September 23, 2.18.2 on October 1 and 2.18.3 on October 9, all ET. The stable branch is STILL on 2.17.10, the hotfix Valve shipped on September 18. Valve has NOT said when 2.18 LEAVES beta.
Steam Frame: SteamOS 0.5.6 Beta adds right-click “Add to Steam” for Android .apk files, plus mic noise suppression. A stable client update improves Wireless Adapter pairing, and SteamVR Beta 2.18.4 fixes startup crashes. #SteamFrame #SteamVR
— VetTV X (@The_VetX) October 18, 2026
The Rest of the Linux Tracker This Weekend
Issue #1020 is NOT the only new report. In the 48 hours around the 2.18.4 release, the SteamVR-for-Linux tracker logged SEVERAL more:
- #1021 (October 16, 2:46 p.m. ET): a developer with many Docker network interfaces found SteamVR bound only to the FIRST 16, which LEFT OUT the Steam Frame Wireless Adapter. Streaming fell back to home Wi-Fi, or FAILED SILENTLY with Wi-Fi off. The report lists the PC on beta 2.18.3.
- #1022 (October 16): SteamVR 2.17.10 on the STABLE branch THREW Error 303, “a key component of SteamVR doesn’t work correctly,” after installing a new Steam Legacy Runtime component.
- #1025 (October 17, 10:26 a.m. ET): a TORN, UNUSABLE dashboard on beta, stable and previous branches. This is the one where Valve ENGAGED: a Valve team member REPLIED within 19 MINUTES, asking whether the Steam client and compositor were on DIFFERENT GPUs, then suggested removing two Vulkan capture and frame-generation layers. The reporter says the dashboard was STILL broken after that.
- #1026 (October 18, 5:11 a.m. ET): on stable 2.17.10 with a Quest 2 over Steam Link, raising per-app render resolution above about 1.3x makes Fallout 4 VR and another title abruptly OVEREXPOSED, which the reporter says looks like gamma applied twice. VRChat at 1.49x is UNAFFECTED.
Tracker issues are USER reports, NOT CONFIRMED bugs, and Valve has NOT RESPONDED publicly to #1020, #1021, #1022 or #1026. But they map where Linux PC VR and the Frame’s own runtime are still ROUGH, WEEKS after the headset began shipping.
What to Watch
Two things will tell readers whether #1020 is a REAL runtime FAULT or a DEVKIT edge case: whether Valve REPRODUCES it, and whether a SteamOS beta for the Frame mentions refresh-rate negotiation in its notes. Until then, developers shipping native OpenXR builds on Steam Frame should TREAT the reported rate as a HINT, not a GUARANTEE, and CHECK the frame period THEMSELVES.