daydream-controls doesn't work

[caseyyee]

daydream-controls doesn't work:

<a-entity daydream-controls>

Looks like isControllerPresent() is returning false in tracked-controls.js

Daydream controller is confirmed to be working on webvr.info/samples

This happens with both Chrome Canary and regular Chrome. I think this may have been due to the controller update I received last week since nothing in the controls seems to have changed.

• A-Frame Version: Master
• Platform / Device: Android Daydream running Chrome and Canary
• Reproducible Code Snippet or URL:

Viewable example: https://iridescent-team.glitch.me

Edit here: glitch.com/edit/#!/join/6963d888-4dfa-4b51-93ce-ba100c9fb78b

cc @machenmusik @cvan for a look-see.

[ngokevin]

Cool, will also check it out. I wonder if the Gamepad ID changed.

[dmarcos]

Does navigator.getGamepads() return anything when presenting? If it does what is the id of the gamepad returned? We're expecting Daydream Controller. Has that changed in Chrome / Canary?

[dmarcos]

The webvr.info examples don't filter by id but take whatever first gameapd they encountered. If I have to bet Chrome just changed the id string and we just have to update it here: https://github.com/aframevr/aframe/blob/master/src/components/daydream-controls.js#L10

[jsantell]

With the latest controller update, the ID string is still "Daydream Controller", and works on the webvr.info examples -- the glitch link above doesn't have any results in navigator.getGamepads() and some errors with loading the DPDB that can be traced back to ONLINE_DPDB_URL being a cached JS object rather than URL from the webvr-polyfill fork, maybe that's the culprit?

[dmarcos]

mmmh... navigator.getGamepads() should return something

[caseyyee]

[caseyyee]

It appears that controller.pose isn't returning anything. Also cloned down the examples on webvr.info/samples and those don't work either. Only seems to work on the webvr.info/samples site.

[dmarcos]

@caseyyee is that an origin-trials side effect? Maybe you have to go and enable webvr on chrome://flags/?

[caseyyee]

Yeah, don't know. I've also been using https to make sure that's a non issue as well.

[caseyyee]

OK interesting. If I let it sit for a while, it will start to work. Not sure why there is a delay. Definetly some kind of weird inconsistency.

[cvan]

OK interesting. If I let it sit for a while, it will start to work. Not sure why there is a delay. Definetly some kind of weird inconsistency.

Order does matter. I'm not sure how things are staggered, but this is the explicit order: query for VRDisplays (or VRDisplayevents), and then query for Gamepads:

let gamepad = null;
navigator.getVRDisplays().then(displays => {
  let gamepad = navigator.getGamepads()[0];
});
window.addEventListener('vrdisplaypresentchange', () => {
  gamepad = navigator.getGamepads()[0];
});

Let me know if that works.

[machenmusik]

If truly required, this explicit order is a little troubling, since it is perfectly reasonable for an experience to provide gamepad functionality outside VR, as well as inside

[cvan]

If truly required, this explicit order is a little troubling, since it is perfectly reasonable for an experience to provide gamepad functionality outside VR, as well as inside

I 100% agree. I'd look at these spec issues: w3c/webvr#184 and w3c/webvr#30 (and its follow-up issue: w3c/webvr#194). Feel free to chime in as well; developer ergonomics are important to address in these specs before these APIs' implementations ship to users.

[machenmusik]

Should try to fix for 0.6.0 yes? If the timing issue is indeed the culprit, then do we need to ensure that getVRDisplays has returned before we allow the tracked-controls system to actually call getGamepads? If so, is there any reliable way to tell whether that has been done (e.g. scene property) ?

[machenmusik]

See latest comments from me on #2769, am not seeing errors mentioned

[caseyyee]

Hey there, as an extra data point.

Here's my tests and what I saw with the Pixel XL this morning:

https://codepen.io/machenmusik/pen/YQGrWQ https://iridescent-team.glitch.me/ https://threejs.org/examples/?q=day#webvr_daydream

For all examples:

Does't work with standard Chrome. No controller at all. Controller only works after interacting or letting it sit for some time (consistent with testing per Issue 2677) before becoming active with both Canary and Beta.

[machenmusik]

Does't work with standard Chrome. No controller at all.

do you have an origin trials tag on any of those that would enable native WebVR via Daydream? Codepen is a no. Frankly, mine are probably expired and I need to update them. Glitch is probably a no. Not sure about three.js...

Do you have the flag thrown manually on Canary and Beta? If you manually set the flag on standard Chrome, does it suddenly start behaving the same?

[machenmusik]

anyone able to answer questions above in https://github.com/aframevr/aframe/issues/2677#issuecomment-303395005?

[machenmusik]

Controller only works after interacting or letting it sit for some time (consistent with testing per Issue 2677) before becoming active with both Canary and Beta.

I thought that interacting was supposed to be required, for security/privacy purposes. The fact that "letting it sit for some time" works surprises me, maybe that's the race condition mentioned above

[machenmusik]

@dmarcos should this be closed like https://github.com/aframevr/aframe/issues/2769#issuecomment-308577969 ?

[dmarcos]

Closing this because for the reasons explained here:

https://github.com/aframevr/aframe/issues/2769#issuecomment-308577969

[machenmusik]

(not closed yet?)