Re: [gamepad] Allow standard-mapped devices to have extra buttons or axes & allow multiple mappings per device

On Mon, Oct 13, 2014 at 3:55 PM, Brandon Jones <bajones@google.com> wrote:

> Re: change #1, with standard gamepad mappings today (at least in Chrome)
> we map any buttons that don't correspond to the official standard mapping
> to button[17] and up. This, of course, depends on which buttons are
> actually visible to the browser (many devices expose buttons that can't be
> "seen" by normal applications, like the home button on Xbox controllers). A
> good example is the Touchpad on the PS4 controller. We can't see actual
> touch inputs without writing a custom driver, but we detect clicks on the
> touchpad and report them as button[17]. The same would go for axes, but
> I've yet to encounter a standard-looking gamepad that exposed > four axes
> worth of usable data. Perhaps the spec should be slightly reworded in this
> regard, since it currently states that "The standard gamepad has 4 axes,
> and up to 17 buttons", which could be read as explicitly disallowing
> buttons or axes beyond that.


Great!  Then I agree - the behavior of Chrome then doesn't match the exact
wording of the spec.  The spec should be updated to reflect reality.

I'm not very supportive of suggestion #2 since we don't actually HAVE any
> other mappings defined (joystick/flightstick would be the next most natural
> candidate, I think, but they can vary significantly). If we did, I'm not
> sure how you would reasonably "stack" mappings without breaking an awful
> lot of code. The "mappings" field would have to be either space/comma
> delimited (which breaks things) or turned into an array (which breaks
> things) or you would expose the same device twice under different mappings
> (which is really weird and probably breaks things.) Beyond that, there's no
> way that the layouts of two mapping types could every overlay completely
> cleanly, and we really shouldn't be claiming that something that looks like
> a racing wheel is actually a "standard gamepad" anyway. I just can't see
> how it would work.
>

What's the status of the gamepad API?  It reads like it's in a draft state,
yet it has some implementations in the wild...  Is it de facto frozen?

Assuming it's not de facto frozen -- and temporarily sidestepping the
problem of maintaining compatibility with existing implementations -- the
issue with the mapping API _as written today_ is that there's only one
standard mapping, meaning that if you plug in any non-XInput-style device
that has a d-pad, you'll need the customer to specify their own bindings.
"Your device is nonstandard.  Press left.  Press up.  Press right.  Press
down.  Press OK."

Beyond that, there's no way that the layouts of two mapping types could
> every overlay completely cleanly, and we really shouldn't be claiming that
> something that looks like a racing wheel is actually a "standard gamepad"
> anyway. I just can't see how it would work.
>

The concern that two mappings that each specify a directional pad would not
have overlapping button IDs is valid.

Fundamentally, what I'd like is access to a richer form of per-button and
per-axis metadata than is provided by the API today.  The "standard
mapping" API provided today is rigid and limiting.  However, I don't have
time to come up with a proposal right now - perhaps coming soon.

+Katelyn as she expressed similar concerns.

Thanks,
Chad