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

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.

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.

--Brandon



On Sun Oct 12 2014 at 11:59:16 PM Chad Austin <caustin@gmail.com> wrote:

> Hi all,
>
> I recently was asked to review the Gamepad API draft specification.  My
> background is games though I've done some scientific computing with
> alternate input devices too.
>
> http://chadaustin.me/2014/10/the-gamepad-api/
>
> I'd like to suggest two simple changes to the Gamepad API.  In tandem,
> these APIs would allow applications to have automatic compatibility with a
> broader range of devices.
>
> The changes are:
>
> 1. Allow standard-mapped devices to have extra buttons or axes
> 2. Add support for multiple standard mappings per device.
>
> Together, these changes would allow a simple application that only needs a
> d-pad and a few buttons to work automatically with a Wiimote, XInput
> device, and a racing wheel (many racing wheels have d-pads on them).
>
> Even without the proposal #2, proposal #1 would allow optional access to
> extra capabilities on a device without having to sacrifice the standard
> mapping.
>
> This feels noncontroversial to me because mappings only assign meaning to
> otherwise neutral indices in the buttons[] and axes[] arrays.  For a given
> device, there can be many such meanings.
>
> --
> Chad Austin
> http://chadaustin.me
>