While testing this API (on http://luser.github.io/gamepadtest/), I noticed my controller was wrongly mapped. I use a cheap no-brand joystick, identified as 79-6-Generic USB Joystick. Specifically, DPad left-right was on the same axis as the right stick up-down. Windows correctly recognizes all controls for this joystick.

Thanks for the report! I'll see if I can give you some diagnostics to run to see what's going on here.

Just joined to say I have a similar issue. My controller is a Logitech Rumblepad2 (corded), with gamepad.id "46d-c218-Logitech RumblePad 2 USB". The DPAD seems to be recognized as an axis, and that axes 4 (left & right) and 5 (up & down), and the right joystick as axes 2 (horizontal) and 5 (vertical). (FF 28, release channel)

Also, axis 3 is not mapped to anything.

Mine works well under Linux: the right joystick is mapped to axes 2 and 3, and the DPAD to axes 4 and 5.

Firefox 31.0a1( x86_64 ) ( 21/03/2014 nightly ) Windows7 64Bit ( x86_64 ) Hello everyone I can confirm that this bug is still exist in Firefox 31.0a1 ( x86_64 ) . I have faced by almost same problem. DPAD Right/Left are correct on the other hand Up/Down axes are mixed with another axes. When i press up or down it returns like i pressed in another axes.(right/left are correct )

I had a chance to try with another gamepad the bug is also exist for that gamepad on the otherhand in that the mapping problem is not in DPAD but in other axes ( this time DPAD shows correct values but another axes mixes its value with DPAD's axes ) So all mixing are generally related to DPAD's axes ( even on some gamepad its value are correct )

This is likely a bug in the POV hat -> axis mapping code: http://hg.mozilla.org/mozilla-central/annotate/199e65efd08b/hal/windows/WindowsGamepad.cpp#l160

Hey guys, just a heads up that Monster Maddness has added support for Gamepad API. They are running into mapping issues and I have sent them this bug number to verify if it's related. To test it out: http://www.playverse.com/Anonplayer/0-a2aadd1b76e14d0e848ea1de18dca4e8 I believe they have added some work arounds.

I'd like to add that a simple Xbox 360 controller (wired) does not appear to be properly mapped either, especially compared to the standard mapping (I get a mapping == "" anyway): https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html#remapping First, I get 10 buttons: - 0(A), 1(B), 2(X) and 3(Y) are mapped correctly - 4(LB) and 5(RB) are mapped correctly - 6(LT) and 7(RT) actually map to select (should be 8) and start (should be 9) - 8(select) and 9(start) actually map to LS (should be 10) and RS (should be 11) - 10, 11, 12, 13 (D-pad) don't exist So basically due to 6 and 7 not being buttons on the Xbox 360 controller, all the buttons past index 5 get shifted by 2 positions... it'd be nice if the mapping still matched the standard mapping. Then, I get 7 axes: - 0/1 for the left stick, mapped correctly - 2 for the left AND right triggers - 3/4 for the right stick, instead of 2/3 - 5/6 for the D-pad, instead of buttons 10-13 Most of these have easy workarounds (since I'm only targetting the Xbox 360 controller for now) but the left and right triggers are a bit of an issue as they cancel each other if pressed at the same time...

Note: the problem I mention above is with Nightly (also tested with Chrome 34.0, where the mapping appears to be correct)

Yes, we don't have any support for the standard mapping yet. I have a patch that adds XInput support in bug 690937 that will cover XInput controllers. That's spec-compliant, we simply don't set Gamepad.mapping=="standard" if we don't have a mapping.

Also, I think the rest of this will be fixed by the backend rewrite in bug 996078.

Just in case it's useful to you (as a test), I quickly extracted/simplified the gamepad-specific from my application: http://pcx360.com/gamepad/

I landed bug 996078 just now, so assuming it sticks you should be able to re-test with tomorrow's nightly and see if this is fixed for you. (In reply to Michael Putters from comment #13) > Just in case it's useful to you (as a test), I quickly extracted/simplified > the gamepad-specific from my application: http://pcx360.com/gamepad/ Very nice! (Doesn't handle non-standard mappings well, but that's not hard to fix.)

Sadly, things are still rough after the rewrite. Now, it presents different problems, such as the right stick having an axis duplicated (i.e., both axes[2] and axes[3] are horizontal, and vertical goes to axes[4]). Also, I have a non-mapped button in buttons[12], which makes the d-pad go from buttons[13] to buttons[16]. Finally, the face buttons are in an weird order logically, but this might be just a issue with my controller.

Yeah, the ordering of the buttons is just "however your controller presents them", including the "buttons that it says it has but aren't actually there". That's unfortunate that your controller still has issues, I've done some fiddling with one of my test apps so you can use it to give me the information your controller presents: http://people.mozilla.org/~tmielczarek/RawInputTest.exe If you run that with your gamepad connected it will produce a devices.out file next to the exe. Send me that file (or attach it here) and I'll see if I can figure out the problem. You may need to install the Visual C++ 2013 runtime to make that binary work: http://www.microsoft.com/en-us/download/details.aspx?id=40784

Gabriel: humorously I just bought a "Retrolink NES USB Gamepad" and it shows up with the exact same USB vendor/product ID as the one you have. Apparently that chipset is popular among cheap gamepad makers. :) I see some of the same problems as you, I'll see if fixing them for my controller fixes them for yours.

Thanks! If you look in the output you can see: {'usage_page': 0x1, 'usage_min': 0x32, 'usage_max': 0x32, 'report_id': 0, 'report_count': 1,} {'usage_page': 0x1, 'usage_min': 0x32, 'usage_max': 0x32, 'report_id': 0, 'report_count': 1,} So it turns out that these gamepads are just made by people that don't understand the USB HID. I'd guess that they're all using the same cheap chipset and not configuring it properly. I could add a bunch of code to special-case this class of controllers, but that doesn't seem very worthwhile. My plan is to fix bug 855364, which will let us fix this in a generic way by adding mappings for any controller. FWIW, the gamepad I mentioned in comment 17 shows up with the d-pad x axis mapped 4 different times, which is pretty silly.