"id" property is unclear how its established

[luser]

Originally filed as https://www.w3.org/Bugs/Public/show_bug.cgi?id=25202:

Oren 2014-03-29 01:38:37 UTC

An identification string for the gamepad. This string identifies the brand or style of connected gamepad device. Typically, this will include the USB vendor and a product ID.

It is a bit vague and could lead to issues for developers because if each vendor builds their own string then developers who do control detection will have compatibility issues.

[reply] [−] Comment 1 Ted Mielczarek [:ted] 2014-03-30 17:55:45 UTC

I think this got spec'ed based on my prototype implementation and we never revisited it. Currently what Firefox does is put -- in the id property.

I wanted the product/vendor ID in there so that content could backfill mappings for controllers that don't provide a standard mapping. The name is nice to be able to present to the user, but not strictly necessary.

Do you have any suggestions for what would make the most sense here? I think maybe specifying that the id property should contain vendor id-product id if available is sensible, and perhaps we should split the name out into a separate name property.

[reply] [−] Comment 2 Brandon Jones 2014-03-30 22:39:34 UTC

Some things to consider:

1. You'd have to be careful about over-specifying the format to depend on signals that may not be present on all devices. For example: I don't think that Android would give you a vendor ID and product ID. XInput devices also don't provide many controller details unless you look at other APIs.

2. Not only could a controller be exposed differently between OSes, but the various browsers on the same OS may expose controller inputs differently. Assuming that ID strings were rigorously enforced across browsers in order to get a complete idea of how a controller is exposed you would then need to look at the id, the OS, and the browser as exposed by the User Agent string. :P The only time that the inputs will reasonably be the same across the board is if they have the mapping "standard", which is well specced.

I think the only reasonable route for developers to take when presented with a controller that doesn't conform to the "standard" mapping is to have the user run through a quick configuration dialog and then save the mapping the users provides.

[reply] [−] Comment 3 Oren 2014-03-31 18:54:05 UTC

Brandon your comments make me feel that the ID should not be exposed to developers at all but instead have them rely on "mapping" attribute. It seems the added benefit to developers of the ID does not out weigh the potential problems of the inconsistency of the IDs.

[reply] [−] Comment 4 Brandon Jones 2014-03-31 19:04:04 UTC

In an ideal world every joystick would have an appropriate mapping, but that simply can't realistically be the case. For instance: In Chrome at the moment giving a gamepad a standard mapping involves getting the gamepad into my hands and letting me make C++ changes to Chrome. Obviously that's not scalable, and is guaranteed to exclude much of the long tail of gamepads not made by Microsoft or Sony.

Having an ID allows users a basic method of capturing and using custom JS mappings, which is a worth cause in my mind.

[reply] [−] Comment 5 Ted Mielczarek [:ted] 2014-03-31 19:11:05 UTC

I think we might be able to mitigate some of the "same controller doesn't map correctly across browsers" issue with more careful spec language.

I suspect the largest difference is handling things like directional pads, which are often represented as neither buttons nor axes (DirectInput and HID often calls them "hat switches"). We could add spec language to indicate how those ought to be mapped to buttons/axes which might be enough to smooth out the cross-browser differences.

There's still likely to be differences across OSes, unless we get every implementation using raw HID input on every OS, and I'm not sure if that's feasible, or if there's a way around that.

[pyalot]

A note on d-pads. It's not technically possible to consistently identify them and map them correctly.

I have an X55 on my table, and I poked at it trough libusb, xinput and evdev. The joystick has 5 dpads (hats). These come in all colors of the rainbow, including:

• 8 buttons for one
• 2 axes for one
• 1 axis for one with 8 states

On a single device...

It's completely illusionary to contemplate you can provide a mapping of anything that isn't going to be grossly wrong sometimes.

[luser]

Sure, that totally depends on the HID descriptor the device provides. I have a pile of gamepads here, I'm pretty well acquainted with the nonsense they do with HID. (I'd be interested to see the HID descriptor for that X55!) What I meant by that comment was merely that in an ideal world the same device on the same OS would be presented the same way by every browser. Since the spec only deals in buttons and axes, d-pads that show up as hat switches are notably absent. If a controller reports a d-pad as buttons, then fine, browsers should show those buttons, and if it reports it as axes, again, fine, they can be axes, as long as it comes out the same across implementations.

[pyalot]

As long as different UAs use the same API on the same OS it will come out the same. Unfortunately that might not be the case.

[marcoscaceres]

Duplicate of #73 ?