requestPresent giving gamepad permissions

[toji]

From @HalfdanJ on October 14, 2016 19:56

Currently a site cannot list gamepads until the user has pressed a button on the gamepad. I understand this privacy decision, but could the requestPresent also be giving permission to the headsets gamepads?

I really like when i put on my Vive headset that i can see where the controllers are. When I dont see them I think they aren't tracked or are off. It would be much more intuitive as an user if when i put on my headset straight away can see my controllers.

Copied from original issue: immersive-web/webxr#117

[toji]

From @memmottse on November 9, 2016 17:26

Since VR rendering is gated by user activation, this makes sense to me.

[toji]

I agree that this should be a valid reason for exposing gamepads. Ideally it would only be gamepads that are directly associated with the headset, but that may be tricky for some implementations. Probably not harmful if it exposed all gamepads like a normal gamepad gesture.

[toji]

From @cvan on November 9, 2016 19:18

Since the gamepads have events, it seems odd to me that I have to call navigator.getVRDisplays() for Gamepad VR controllers to be available. What if I am relying on the events on window to check the display to render to?

I would have to call navigator.getVRDisplays().then(() => {}) just for controllers to show up, even if I am don't care about the displays getting resolved?

Can we choose a better signal, such as the proposed meta http-equivalent/header, for identifying VR content or not?

Either way, is there text in the current spec that actually specifies this behavior? Know this has come up in other issues.

[toji]

Given that VR gamepads typically aren't available unless the entire VR API is initialized, exposing them automatically would mean spinning up any VR hardware any time navigator.getGamepads is called or gamepadconnected events are listened to on the off chance that they care about VR controllers. That seems bad and counter-intuitive to me. (Also, I'm finding that some controllers aren't available until you are actively presenting.)

As such I don't think it's a bad idea to ensure that the page has shown SOME interest in VRDisplays before making these available. The traditional method is, of course, navigator.getVRDisplays, but I imagine that listening to connected events or the aformentioned meta tag would also serve as strong signals that make it worthwhile to spin up the VR systems and start delivering VR controllers to the gamepad API.

[toji]

From @cvan on November 9, 2016 19:44

I propose instead we also listen for any vrdisplay* event listener is set (on window or the VRDisplay instances when we have navigator.vr namespace in 1.2+). Does that work? Otherwise, developer ergonomics are pretty ambiguous and make for unpredictable behaviour.

[toji]

That's basically what I was suggesting. I'm not going to spin up the VR systems if the only event you listen to is, inexplicably, vrdisplaydisconnect. So maybe not all vrdisplay events. ;)

[toji]

From @cvan on November 9, 2016 19:58

Great, that's an improvement on what I was thinking. I wasn't 100% clear based on the comment above, but looks like we are speaking the same language. :)

• navigator.activeVRDisplays
• navigator.getVRDisplays()
• window.addEventListener('vrdisplayconnect')
• window.addEventListener('vrdisplayactivate')
• window.addEventListener('vrdisplaypresentchange')

And we shall revisit these when navigator.vr namespace and event changes make it into the spec. Sound fair?

[toji]

SGTM

[toji]

From @HalfdanJ on December 7, 2016 19:34

Is this something that could make it into WebVR 1.2?

[toji]

From @cvan on March 6, 2018 3:52

@toji: in favour of the new proposed input model, can this issue be closed or merged into other relevant issues (I see a few)?