This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27444 - Gamepad objects should have a dictionary of attributes about the controller and data source
Summary: Gamepad objects should have a dictionary of attributes about the controller a...
Status: RESOLVED MOVED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Gamepad (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Ted Mielczarek [:ted]
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-26 14:34 UTC by Ted Mielczarek [:ted]
Modified: 2015-04-24 11:00 UTC (History)
4 users (show)

See Also:


Attachments

Description Ted Mielczarek [:ted] 2014-11-26 14:34:46 UTC
A few weeks ago some interested parties had an informal meetup at the Mozilla office to discuss the issues surrounding the Gamepad API as-implemented. The biggest issue we noted is the inconsistent mapping of controls across browsers and operating systems. We talked at length about this, and it feels like a really hard problem to solve. A number of people have written content libraries to try to smooth this over (including myself and Scott):
https://github.com/luser/gamepadmapping.js
https://github.com/sgraham/gamepad.js
http://mozilla.github.io/galaxy.js/docs/galaxy.js.html#getGamepads

However, because of the differences across browsers and OSes the complexity blows up quickly. (Example: https://github.com/luser/gamepadmapping.js/blob/6dae0a5751df4acacfae2a5d3619758b7bb4bf43/gamepadmapping.js#L90 )

Specing things to remove this complexity might be possible, but it would be hard. We think as a stopgap we can make things better by simply exposing more information about the controller and the source of the data in a structured manner, to allow content libraries to make better choices.

Right now there's an "id" string on the Gamepad object that is basically unspecified (bug 25202). We should deprecate that in favor of a dictionary of useful attributes. My proposal would be something like this:

dictionary GamepadAttributes {
  unsigned short? vendorId;
  unsigned short? productId;
  DOMString name;
  GamepadDataSource dataSource;
};

enum GamepadDataSource {
  "hid",
  "xinput",
  "linuxjoy",
  // other values
};

interface Gamepad {
  GamepadAttributes attributes; // Probably needs a better name
  ...
};

We'd like to see how well we can do with content libraries if we give them better data, and this feels like it ought to be enough to work with.
Comment 1 Boris Zbarsky 2014-11-26 15:19:39 UTC
This should probably be an interface, not a dictionary.
Comment 2 Ted Mielczarek [:ted] 2014-11-26 15:24:11 UTC
I kind of wanted to leave some wiggle room for implementers to extend this, but I guess you can put arbitrary non-spec attributes on an object that claims to be a particular interface anyway, eh?
Comment 3 Boris Zbarsky 2014-11-26 15:32:26 UTC
Indeed.
Comment 4 Ted Mielczarek [:ted] 2015-04-24 11:00:10 UTC
Moved to https://github.com/w3c/gamepad/issues/12