The last state of the experiment, kept on this branch only:
- input/gazefirst.py, input/steamui.py: the relay reading the controllers from
vrserver's web socket, switching the compositor binding, and driving the Steam
UI filter (whose block now expires unless renewed).
- The helper's trigger and bumper holds (steered by the controller's position),
the laser keeper, and the click gate that waits for the laser.
- pointer/probe/focustest (overlay flag 1 << 4, as an input client too),
vrsetting (SteamVR settings through vrserver), lasertest --reclaim.
Every press and release Steam sees takes SteamVR out of laser mode, and taking
the laser back breaks clicks and drags. See docs/gaze-controllers.md on
experimental.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
From the first headset tests (docs/gaze-first.md, "Test results"):
- SteamVR gives the treadmill path only to a device that hints it when
it's added, so the driver hints a role that's no hand from Activate
(a hand still only while shown). With it, our device held the
dashboard laser with no hand role. The helper doesn't release the
pointer for having no hand role when POINTER_ROLE is treadmill.
- The helper's global action sets can't mute the compositor (SteamVR
reports them inactive while the laser mouse has focus), but selecting
pointer/bindings/vrcompositor_frame_controller_gazefirst.json (the
stock binding without its trigger and bumper laser entries) through
vrserver's /input/selectconfig.action does.
- input/vrws.py follows devices that connect later.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
