Input and authority
Every interactive element in vrOS is focusable, labelled, and sits in a defined traversal order. Nothing is hover-only. Nothing activates on gaze alone. Destructive actions are always two steps, never a single dwell, and never the focus default.
| Modality | Point | Confirm | Scroll | Text |
|---|---|---|---|---|
| Laser and controller | ray | trigger | stick or drag | the VR keyboard |
| Gaze and confirm (designed, not in the build) | eye gaze | a bound button, or opt-in dwell | stick | the VR keyboard |
| Gamepad only | focus traversal (d-pad or stick) | A | stick | d-pad walks keys, A presses |
| Desktop | mouse | click | wheel | your hardware keyboard |
Hit targets are sized in degrees, not pixels: 2.0 degrees minimum for a laser, 3.0 degrees when gaze pointing is on, with at least 0.75 degrees between gaze targets. When the enabled modality set changes, a surface re-resolves to fewer and bigger controls. The same thing happens at UI scale 1.25x and above.
Laser and controller
Section titled “Laser and controller”Point with the ray, pull the trigger to click. The stick scrolls.
Click and drag are told apart before any event reaches the OS. Trigger-down arms a small angular deadzone; release inside it gives a clean click at the press point, and exceeding it starts a drag from the press point with no motion lost. The deadzone (0.30 degrees) and the flick slop (0.80 degrees) are in Settings → Accessibility.
Bindings live in SteamVR, not in gestures vrOS invents. On the shipped defaults, a double-press of a face button on your left controller shows and hides the keyboard, and the same press on your right controller shows and hides the Dash; which physical button that is depends on your controller profile. The Controls pane in Settings shows the binding words SteamVR reports and can open SteamVR’s binding editor. On a desktop with no VR runtime running, that button is dimmed rather than hidden.
Gaze and confirm
Section titled “Gaze and confirm”Gaze is designed in throughout: layouts carry the 3.0-degree floor, focus acquisition uses hysteresis so jitter cannot flicker focus, and nothing moves or animates under gaze — a fixation must never have to chase its target. Dwell, when it arrives, is opt-in, 800 ms, and 1600 ms on anything destructive.
Gamepad only
Section titled “Gamepad only”Traversal runs top to bottom. Left and right adjust a value in 5% steps. Arrows clamp at the ends of a list; Tab wraps. Clicks and focus do not fight: a click acts without stealing the visible ring, but it moves the traversal cursor to what you clicked, so the next d-pad press rings the neighbouring control rather than sending you back to wherever the ring last was.
Desktop mouse and keyboard
Section titled “Desktop mouse and keyboard”The desktop window runs the same surfaces at desktop density — 52 px rows, 28 px targets, 1 px borders — and hover comes back as tooltips and row actions, always with a right-click or keyboard equivalent beside it. See the desktop app.
Input authority
Section titled “Input authority”vrOS forwards your controller clicks and your VR keystrokes to your own focused window, the way an on-screen keyboard or a remote-desktop client does. One explicit rule decides when it is allowed to.
The moment you touch your physical mouse or keyboard, vrOS yields. No cursor fighting, no focus stealing, no stray injected events. It starts in that state: until you deliberately click something in VR, vrOS injects nothing at all.
What hands off
Section titled “What hands off”- Any genuine physical mouse event — a button, the wheel, one pixel of motion — flips authority to the desktop on that same event.
- Typing keys hand off. Bare modifiers, F-keys, arrows and Escape do not, so a VR-bound macro key does not drag your cursor back to the desk.
- Real input is told apart from injected input. On Windows, by the documented injected flags plus vrOS’s own marker on every event it emits. On Linux, by device identity: anything that is not vrOS’s own virtual device is you.
- A handoff mid-drag closes cleanly. Any button vrOS is holding gets a proper release, and those releases are the last events it sends. Zero injected events after a yield.
What takes it back
Section titled “What takes it back”Only an explicit trigger pull on a capture panel. Controller motion never reclaims, and neither does hover. The pulling hand has to be tracked and engaged, so a controller parked on your desk cannot yank the cursor with a bumped trigger.
Both channels have to have gone quiet first, and for how long depends on what you just did:
| What you did | Reclaim locked out for |
|---|---|
| Brushed the mouse (a few px, no click) | 400 ms |
| Used the mouse (about 40 px of travel inside 300 ms, or any click or wheel) | 1 s |
| Typed | 3.5 s |
Typing gets the longest window because reading and thinking pauses of one to three seconds are normal, and handing the cursor away mid-sentence is worse than waiting.
What still works while your desk owns input
Section titled “What still works while your desk owns input”Lasers keep working on vrOS’s own surfaces. You can move a panel, drag a slider, or change a setting with a controller while your hands stay on the keyboard — none of that injects anything into another window, so none of it consults the arbiter.
The VR keyboard stays where it is but goes inert for captured windows: no key state, no click sound, no haptic. A key that types nothing should not feel like it typed. Typing into vrOS’s own text fields keeps working, and composition survives the handoff — see the VR keyboard.
The authority chip
Section titled “The authority chip”The live mode is always visible, as a dot and a word at the bottom of the rail in both the Dash and the desktop window.
| Chip | Meaning |
|---|---|
| VR | The VR pointer may inject. Your trigger clicks reach the captured window. |
| DESKTOP | Your desk owns input. vrOS is injecting nothing. |
The word carries the meaning; the dot colour only reinforces it. If clicks in a captured window are doing nothing, read the chip first — see Troubleshooting.