Oculus touch controllers are not working properly if "Oculus hardware support" flag is enabled and "OpenVR hardware support" flag is disabled
Reported by
sourov08...@gmail.com,
Mar 28 2018
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce the problem: 1. Enable "Oculus hardware support" & disable "OpenVR hardware support" 2. Turn SteamVR on 3. Go in WebVR 5. Get the left controller from the gamepads array using the id 'Oculus Touch (Left)' 4. Check the values of the "IndexTrigger"(button index 1) and "HandTrigger"(button index 2)'s "pressed", "touched" & "value" property. What is the expected behavior? The value of the "pressed" property should be true when we press the "IndexTrigger" and "HandTrigger". Also the value of the "Value" property should be between 0 and 1 depending on the position of the trigger. What went wrong? The value of the "pressed" property is always false. The value of the "Value" property is always 0. Only the value of the "touched" property is updated properly. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 67.0.3382.0 Channel: canary OS Version: 10.0 Flash Version: Also, if "OpenVR hardware support" is enabled and "Oculus hardware support" is disabled then the controller's id is always "OpenVR Gamepad". Doesn't matter if Oculus or Vive is connected. This is different from Firefox.
,
Mar 30 2018
As TE team do not have VR headset to test this issue adding TE-NeedsTriageHelp label for further investigation from dev team. Thanks!
,
Mar 30 2018
I'll take a look.
,
Apr 3 2018
,
Apr 10 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ed2b4dc48aa66907b84f9ae5e269937035d047cf commit ed2b4dc48aa66907b84f9ae5e269937035d047cf Author: Bill Orr <billorr@chromium.org> Date: Tue Apr 10 18:36:19 2018 Fix Oculus trigger deadzone so triggers are exposed through gamepad API The issue here is that the gamepad API will only expose a button if it has been interacted with, to ensure logic for requiring user gestures works correctly when a gamepad is faulty or has some weight pressed on it. Oculus touch triggers don't have a deadzone already applied, so the logic to detect if they have been interacted with always returns false. The fix is to apply a deadzone ourselves. BUG= 826714 Change-Id: I690e71283670bd30c6bdf0731ff5456d5d1eb112 Reviewed-on: https://chromium-review.googlesource.com/996519 Commit-Queue: Bill Orr <billorr@chromium.org> Reviewed-by: David Dorwin <ddorwin@chromium.org> Reviewed-by: Brandon Jones <bajones@chromium.org> Cr-Commit-Position: refs/heads/master@{#549601} [modify] https://crrev.com/ed2b4dc48aa66907b84f9ae5e269937035d047cf/device/vr/oculus/oculus_gamepad_data_fetcher.cc
,
Apr 11 2018
>>> Also, if "OpenVR hardware support" is enabled and "Oculus hardware support" is disabled then the controller's id is always "OpenVR Gamepad". Doesn't matter if Oculus or Vive is connected. This is different from Firefox. This point is acknowledged, but not something that will be fixed now, recommended short-term workaround is to use the Oculus flag for Oculus hardware if it makes a difference. Longer-term, the WebXR input API doesn't expose a string ID, so new hardware will work with existing pages as it comes online. String comparisons and only handling specific hardware is something we should avoid.
,
Apr 11 2018
,
Apr 23 2018
Issue 835440 has been merged into this issue.
,
May 10 2018
,
Jul 4
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by susan.boorgula@chromium.org
, Mar 28 2018