Space drag aborts itself every frame on SteamVR: committing the chaperone raises the event that cancels the drag #678

Description

Space drag is unusable with the SteamVR backend on the Steam Frame: holding the drag chord makes the playspace spin / never settle instead of dragging. Nothing is actually dragged — the playspace is repeatedly reset while the chord is held.

WayVR's own log (/tmp/wayvr.log) shows the drag being cancelled by WayVR itself, once per frame:

2026-10-08T17:28:20.817018Z  INFO wayvr::backend::openvr::playspace: wayvr/src/backend/openvr/playspace.rs:180: Start space drag
2026-10-08T17:28:20.839344Z  INFO wayvr::backend::openvr::playspace: wayvr/src/backend/openvr/playspace.rs:344: Space drag interrupted by external change
2026-10-08T17:28:20.839531Z  INFO wayvr::backend::openvr::playspace: wayvr/src/backend/openvr/playspace.rs:180: Start space drag
2026-10-08T17:28:20.861228Z  INFO wayvr::backend::openvr::playspace: wayvr/src/backend/openvr/playspace.rs:344: Space drag interrupted by external change
2026-10-08T17:28:20.861424Z  INFO wayvr::backend::openvr::playspace: wayvr/src/backend/openvr/playspace.rs:180: Start space drag
2026-10-08T17:28:20.883372Z  INFO wayvr::backend::openvr::playspace: wayvr/src/backend/openvr/playspace.rs:344: Space drag interrupted by external change
... (alternating like this for ~16 s) ...

Counts over that one held drag: 113 × Start space drag, 111 × Space drag interrupted by external change (17:28:20.82Z → 17:28:37.03Z, the log is 266 lines and almost nothing else).

What I think happens, from the source:

1. The drag path writes the chaperone working copy and commits it: chaperone_mgr.commit_working_copy(EChaperoneConfigFile_Live) in backend/openvr/playspace.rs.
2. That commit makes SteamVR raise VREvent_ChaperoneChanged / SeatedZeroPoseReset / StandingZeroPoseReset.
3. backend/openvr/mod.rs dispatches EV_SEAT_ZERO | EV_STAND_ZERO | EV_CHAP_CHANGED | EV_SCENE_CHANGED to playspace_changed(), which cancels the active drag. The if self.drag.is_some() cancel block sits outside the if new_universe != self.universe guard, so it fires on WayVR's own commit too, not only on a genuine external change.
4. The chord is still held, so the next frame starts a new drag and it repeats.

So WayVR's own write raises the event that aborts its own drag, at frame rate.

SteamVR's side of the same 16 s (vrserver.txt) — roughly 50 chaperone commits in the first seconds and then ~7/s, each one producing:

Processing message VRMsg_UpdateChaperoneUniverse from <wayvr pid>: wayvr took 0.00677 seconds
CVRChaperoneServer::HandleChaperoneUniverseUpdated: Seated origin changed.  Sending reset seated zero pose event
CVRChaperoneServer::HandleChaperoneUniverseUpdated: Standing origin changed.  Sending reset standing zero pose event
cv: [CLighthouseHmdDriver] receive a manual ResetSeated event
cv: [CLighthouseHmdDriver] receive a manual ResetStanding event
[CVRChaperoneServer] Wrote chaperone data to .../chaperone_info.vrchap

with the chaperone universe id different on every commit, and it ends when the tracking driver gives up:

cv: [CCVTrackedHmdDriver] Switch to the dummy chaperone universe 424242

The same path on a PC-side install (SteamVR 2.18.2 beta, CachyOS, x86_64) shows the same thing more mildly: space drag applies but never persists, because the runtime isn't resetting the playspace on every commit there.

System Info

Linux Distribution: SteamOS 0.4.3 (BUILD_ID 20260930.6234839), aarch64 / Steam Frame
Desktop Environment: SteamOS Game Mode (gamescope); echo $XDG_CURRENT_DESKTOP is unset in that session
Kernel version: 6.18.0-ge66bc2ca6f8c

VR Runtime:

• Monado
• WiVRn
• ALVR
• SteamLink
• SteamVR (not SteamLink)

GPU models and driver versions:

GPU0:
    apiVersion         = 1.4.362
    driverVersion      = 26.2.99
    vendorID           = 0x5143
    deviceID           = 0x43051401
    deviceType         = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
    deviceName         = Turnip Adreno (TM) 750
    driverID           = DRIVER_ID_MESA_TURNIP
    driverName         = turnip Mesa driver
    driverInfo         = Mesa 26.3.0-devel (git-abc426bb62)

WayVR: 26.8.0-745728d (AppImage) — from the Welcome to wayvr version ... line, which is the only place that identifies the build (X-AppImage-Version=main does not).

Overlay Logs

/tmp/wayvr.log (266 lines) — WayVR writes this file itself on the Steam Frame, where it is started from the headset's launcher rather than a terminal. The loop excerpt is inline above; the same file also logs:

WARN wayvr::backend::openxr: .../openxr/mod.rs:81: Will not use OpenXR: Missing EXTX_overlay extension.

i.e. it falls back to the OpenVR backend here.

Config in use:

"space_drag_multiplier": 1.0,
"space_drag_unlocked": true,
"space_drag_affects_world": false,
"space_gravity_enabled": false,
"space_rotate_unlocked": false,

Input used: chord [left grip single] + [left dpad_left single] → /actions/default/in/spacedrag.