Gamepad API is outputting strange values for buttons
Reported by
chrismr3...@gmail.com,
Apr 4 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36 Steps to reproduce the problem: 1. Connect a logitech Driving Force GT 2. Press X button and D-Pad buttons What is the expected behavior? The Dpad buttons to each be their own button and the X Button to not be magically pressed when it isn't What went wrong? The X button appears as pressed and the DPad for some reason appears as a Frankenstein-ed sort of axis. Did this work before? N/A Chrome version: 49.0.2623.110 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 21.0 r0 Admittedly it's a fairly niche thing to have a driving wheel connected and have it's output read in chrome, but what bothers me the most is how Firefox somehow has this set up correctly and chrome does not (as can be seen at http://chrisr.xyz/s/2016-04-04_00-48-42.mp4 ).
,
May 4 2016
Issue 393164 has been merged into this issue.
,
May 4 2016
Thanks for the heads up. Much appreciated.
,
May 4 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a8d9d22865f445b8f6f2b9814fb919b8008fbc5c commit a8d9d22865f445b8f6f2b9814fb919b8008fbc5c Author: aicommander <aicommander@gmail.com> Date: Wed May 04 20:08:27 2016 Fix button 1 being stuck down on certain Logitech gamepads on Windows There are HID elements in these gamepads classified as buttons which don't use the usage page value for buttons. These elements don't actually correspond to real buttons on the controller, and are stuck in the pressed position. On OSX, we skip these "fake" buttons, but we didn't on Windows. As a result, a HID element would overlap with button 1 and make it appear to be constantly pressed. R=bajones@chromium.org BUG= 600230 Review-Url: https://codereview.chromium.org/1950883002 Cr-Commit-Position: refs/heads/master@{#391616} [modify] https://crrev.com/a8d9d22865f445b8f6f2b9814fb919b8008fbc5c/content/browser/gamepad/raw_input_data_fetcher_win.cc
,
May 23 2016
aicommander@: Shall we close this if there is no further work to be done on this.
,
May 23 2016
Well, there's still the missing mapping for certain d-pads. I'm still unsure why Firefox can somehow have that displayed correctly and chrome can't.
,
May 23 2016
Firefox will automatically convert axis 9 (HID usage 0x39, specified to be a D-Pad) into buttons. That's the reason you see buttons instead of an axis. Chrome doesn't do that, so you see the raw axis that the device exposes. It wouldn't be difficult to duplicate Firefox's behavior, but I want to have a discussion/resolution on the regression in 613429 before making further HID changes.
,
May 23 2016
@#7, Thanks for the reply. Since it would seem that the other part of this bug has been fixed, I'd say it's probably fine to close this report. Also, if you need a more visual representation of Gamepad API data, feel free to use my own tool http://gamepadviewer.com/. There's also a live raw output similar to html5gamepad.com's in the remapping modal, just make sure to select the appropriate player.
,
Jan 30 2017
As ^
,
Apr 27 2017
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by aicomman...@gmail.com
, May 4 2016