[PC][VR] Steam Frame: all input lost after opening Steam menu, restart needed

Every time I open the Steam menu on my Steam Frame while playing F1 25 in VR (even just to press "Resume Game"), the game stops responding to my wheel and keyboard completely. The only way to get them back is to quit and restart the game, which means the current game is lost: whatever race, qualifying or career session I was in is gone. This is very frustrating, because one accidental button press is enough to throw away the whole session.

Below are the details for the dev team: steps to reproduce, what I found, and a suggested fix. I investigated this with the help of Claude, which captured the SteamVR events, found the cause and built the workaround described below.

SETUP

• Platform: PC, Steam (app 3059520, build 25251167, F1_25.exe 1.0.141.7865)
• Mode: VR (-vr), OpenVR (openvr_api.dll 2.7.1)
• Headset: Valve Steam Frame (SteamOS 0.4.5), streamed wirelessly through the Valve 6 GHz adapter
• SteamVR 2.18.4 beta (Steam build 25998080) Windows 11 Pro (build 26200), RTX 4070 Ti, NVIDIA driver 617.14
• Inputs: MOZA R5 wheel base and keyboard

STEPS TO REPRODUCE (happens every time)

1. Start F1 25 in VR on a Steam Frame.
2. Check that the wheel and keyboard work (in a menu or on track).
3.  Press the Steam button on the Frame (or a controller button that opens the Steam menu). The Steam menu opens.
4. Select "Resume Game".

Actual result: the game keeps rendering and head tracking still works, but from then on it ignores all keyboard and wheel input, both in menus and on track. Only restarting the game brings input back.

Expected result: input works again as soon as the menu closes.

These do NOT bring input back:

• Alt+Tab or clicking the game window
• Opening and closing the menu again
• Taking the headset off until it goes to standby
• Opening and closing the SteamVR dashboard from the PC (vrcmd --showdashboard / --hidedashboard)
• Restarting the Steam overlay process

WHAT WE FOUND

While its menu is open, the Steam Frame's SteamVR driver sets Prop_DriverRequestsApplicationPause_Bool (plus DriverRequestsReducedRendering), and it clears them when the menu closes. A capture with "vrcmd --showevents" shows the close events arriving in this order, within the same millisecond:

VREvent_DashboardDeactivated

  VREvent_PropertyChanged Prop_DriverRequestsApplicationPause_Bool (~26 microseconds later, now false)

So when F1 25 handles DashboardDeactivated, the driver's pause request is still set. Our best guess is that the game checks IVRSystem::ShouldApplicationPause() (or that property) at that moment, sees "still paused", keeps input disabled, and never checks again when the flag clears a few microseconds later. Other headsets probably don't set this driver flag, which would explain why this only happens on the Steam Frame.

Confirmation: sending one extra VREvent_DashboardDeactivated about 1 second after the menu closes, using SteamVR's own tool ("vrcmd.exe --send-vrevent 503"), brings input back immediately, every time we tried. Sending it while the game is not stuck does no harm.

WORKAROUND (for other players hitting this)

After the Frame menu closes, run this once (with F1 25 focused afterwards):

  "C:\Program Files (x86)\Steam\steamapps\common\SteamVR\bin\win64\vrcmd.exe" --send-vrevent 503

I use a small script that does this automatically about 1 second after every Frame menu close.

I can share the SteamVR logs (vrserver.txt, vrclient_vrcompositor.txt, vrclient_F1_25.txt) and the event capture if that helps.

Thanks!