DPAD/HAT mapping issues about sdl_gamecontrollerdb HOT 10 CLOSED

h0.3, h0.6, h0.12, h0.9 are combinations of up/down/left/right. 1|2, 2|4, 4|8, 8|1. Used in dpads with diagonals.

SDL_HAT_RIGHTUP
SDL_HAT_RIGHTDOWN
SDL_HAT_LEFTUP
SDL_HAT_LEFTDOWN

I've recently updated the db and removed many h0.0 mappings that were problematic. I've also added some tests to make sure we don't get duplicate mappings (edit: Which should ring bells when this happens). Have you tested with the latest db from yesterday?

edit: h0.0 is valid. It is SDL_HAT_CENTERED.

from sdl_gamecontrollerdb.

Oh and it seems low-quality controllers were giving sporadic inputs, and (if IIRC) SDL2.0.6 added a jitter filter. Maybe that's where these were coming from?

from sdl_gamecontrollerdb.

SDL gets values for HAT/DPAD directions from the system - there are only UP/DOWN/LEFT/RIGHT values (you can see this in the source code). When you press in a diagonal direction, you get a combined value of the two base directions. When no direction is being pressed, the value received is 0 (i.e. "centered")... a value received by SDL when you RELEASE the HAT/DPAD (not when you PRESS a direction).

For the purpose of SDL "gamecontroller mapping", the user should be pressing a single direction like UP on a HAT/DPAD that "feels right" if one pretends the device is an XBOX pad. There is a very small chance that pressing UP on the physical HAT/DPAD control on a physical device could produce one of the combined diagonal values (maybe if the DPAD is diagonal on the physical device or such) but it's highly unlikely. Practically speaking, it's tough to press a diagonal perfectly on many DPAD controls, first try, without hitting up/down/left/right first for a split second before achieving the diagonal. Likewise it's pretty easy to first press UP+LEFT before achieving a pure UP direction on many DPADs without being very careful.

So given that the input value coming from SDL is h0.X (i.e. the input is coming from a HAT/DPAD control on the physical device) and given that the user is supposed to be pressing up/down/right/left direction on that HAT/DPAD (which might be a different value than up/down/left/right pressed on a real XBOX gamepad), diagonal values and centered values should be ignored

from sdl_gamecontrollerdb.

Link to the code please. From what I can tell, the diagonals are valid, are tested for and can be returned at an OS level. See linux/SDL_sysjoystick.c : HandleHat and windows/SDL_dinputjoystick.c : TranslatePOV.

Again, from what I can tell, diagonals are valid values. I'm not saying they are necessarily right. But those values can be returned from the input processing, which means a gamepad could have a strange binding that returns these. Are you telling me with confidence that no gamepad on the planet can return these values? Same goes for centre.

Have you looked at the db recently? Please list the problematic bindings so we can deal with real problems (vs. theoretical issues). I'm all for more checks or tests, and you are right these values are suspicious, but I can't outright disallow them if they can be returned by SDL input processing.

from sdl_gamecontrollerdb.

I've been studying the controllermap program that comes with SDL and you are right for h0.0. Centered hats are actually ignored in the newer controllermap versions. As such, I'll be taking appropriate actions on the db and adding tests for that hat (and removing/replacing the hats with the most appropriate values if possible).

            case SDL_JOYHATMOTION:
                if (event.jhat.which == nJoystickID) {
                    if (event.jhat.value != SDL_HAT_CENTERED) {
                        /* ... */
                    }
                }
                break;

For diagonals, controllermap does use them. I'm still uncomfortable removing/testing for these. I will however try and contact the appropriate SDL input developers for some guidance.

from sdl_gamecontrollerdb.

The main issue with controllermap.c from SDL is that it doesn't give the user a way to press the DPAD/HAT in a direction and then confirm that it's in the correct direction before saying "okay, now I've got it pressed in the correct direction - take the reading". Given how fidgety these DPAD/HAT controls are, it really needs to confirm. I see there is a feature where you can hit backspace to undo the last mapping and try again at least. The problem is, there's no feedback so the user can tell what got mapped except h0.9 buried in the mapping string after it's all too late. If I want to press UP on the DPAD on my device, I can't tell if it was a perfect UP event or if it was some trail of events like UP+RIGHT then UP, or UP+LEFT then UP. The program just grabs the first event that comes through even if it's wrong (with with your typical DPAD or HAT on a gamepad/joystick, it's easily wrong).

from sdl_gamecontrollerdb.

030000004b120000014d000000000000,NYKO AIRFLO,a:b0,b:b1,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b10,leftshoulder:a3,leftstick:a0,lefttrigger:b6,leftx:h0.6,lefty:h0.12,rightshoulder:b5,rightstick:a2,righttrigger:b7,rightx:h0.9,righty:h0.4,start:b9,x:b2,y:b3,platform:Windows,

This gamepad is like a PS2 controller. The mappings are just a mess. The leftx/lefty and rightx/righty shouldn't be DPAD input h0.XX since the h0 inputs are already mapped to dpup/down/left/right correctly. rightstick shouldn't be a2. leftstick shouldn't be a0.

I think the user who created this was really confused. I'd bet one would be better off just using a mapping string for one of the other PS2-alikes.

controllermap.c shouldn't allow you to map the DPAD/HAT to something when it's already used for something else. Come to think of it, it shouldn't let you map ANY input to more than one control in the mapping string.

Also, any analog axis that is assigned to a digital input (i.e. a button or DPAD/HAT direction) is suspect. Using an analog stick to simulate DPAD/HAT directions is certainly allowable (when there is no DPAD/HAT)... but again, controllermap should filter the input diagonals on DPAD/HAT controls just like it doesn't allow you to use two analog axises (a1+a2) for "leftx" just because you move it diagonally when controllermap waits for you to press/move something on the device.

Check out how a POV/HAT/DPAD works in DirectInput here:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms835032.aspx

SDL just reads the value and turns it into the SDL direction. So pressing UP on any POV control in DirectInput produces this 0 value which turns into SDL_HAT_UP or 1 (see the "TranslatePOV" routine in src/joystick/windows/SDL_dinputjoystick.c). There's no gray area here. The only problem is when a device driver is screwed up (with USB + HID, I rarely install a driver any more).

I notice that in gamecontrollerdb.txt currently there are no cases of dpup:h0.X where X != 1. YAY!

In general because these are DirectInput devices and because of the way POV/HAT/DPAD controls work in DirectInput, the mapping string should always be:

dpup:h.01,dpright:h0.2,dpdown:h0.4,dpleft:h0.8

Any DirectInput device that doesn't match this is suspect, and either the mapping is messed up, or the driver is not following the specs... in which case, a carefully made mapping string can make it work physically correctly to emulate an XBOX pad (except the diagonals might not work because the "OR" math doesn't work when the directions are not the correct values).

from sdl_gamecontrollerdb.

I think you should bring up your issues with controllermap in the official SDL forums. This project doesn't have any ties to SDL whatsoever.

As you've noticed, I've been going through the db and cleaning things up. I also add unit tests when I find new problems. A lot of the problems you have raised are already dealt with.

I have a few options regarding the issues left.

I'm considering adding warnings in the test script. To flag things that are "correct" in the technical term, but suspicious.

• Dpad hats 3,6,9,12 could raise warnings, with a clear not-too-technical message like "Diagonal input detected, are you sure that is what you want?".
• Duplicate use of a button/axis could raise a warning.

I have to check the SDL database and see if they have duplicate buttons/axis mapped to different functions of the controller.

Regarding the NYKO AIRFLOW mapping, I know it's a mess, but thanks for pointing it out. I may remove it completely from the db.

from sdl_gamecontrollerdb.

Thanks! I think this issue is resolved except for the NYKO AIRFLO.

The NYKO AIRFLO (80650) is $15 so I've ordered one.

from sdl_gamecontrollerdb.

Fixed

• h0.0 mappings removed.
• h0.0 test added.
• h0.3, h0.6, h0.12, h0.9 mappings removed (may cause issues in NYKO AIRFLO, will wait and see if users complain about it).
• h0.3, h0.6, h0.12, h0.9 test added.

@EddieRay It's been a long discussion, thanks for sticking with it :)

from sdl_gamecontrollerdb.