I will have to test this with my PS2 controllers.
Wait for hat + multi-axis on DirectInput support first, please :)
Do i understand correctly that you currently do not support the pressure sensitive buttons, instead treating them as pressed once they go over 50% pressure?
The pressure-sensitive buttons are screwy.
Basically, a thumb is centered at 0, 0. When you move it left, you get -32767, 0. Right = +32767, 0. Up = 0, -32767. Down = 0, +32767. It's two axes in one, and not pressing anything means you're centered at 0, 0.
But the buttons ... they start at +32767, and the harder you press them, the lower the value gets, down to -32767.
My mapping code works with the centered mode, and it tries to not let you assign keys by just
barely tapping them. Reason being when you go to assign 'Up', you'll probably be a little to the left or right, so I don't want 'Down' right after to get assigned immediately. Sometimes you'll hit left or right some before up registers, too.
Because of that, I make a ~75% dead-zone in either direction, so that the stick has to be pretty obviously in a given direction to map to it.
That screws with these buttons badly. It means just barely tapping them will cause them to assign, while the middle area does nothing. If you open the assign window with button released and push it a bit, it gets assigned as ::hi, and it ends up thinking the button is held down when it's not. You have to press the button in to release it. Now, if you start the window with the button held down and let go, it maps it as ::lo, and you have to press down at least 75% of the way to trigger it. If you map both ::hi and ::lo, well ... have fun controlling the game that way :P
I also can't add sensitivity to the upper and lower bounds to make mapping these buttons harder, because a lot of drivers will map real D-pads (or POV hats) as analog axes, especially with those mode buttons. In that mode, left returns a hard -32767, center 0, etc. So if I require even ~1 for tolerance it won't allow mapping at all.
To protect against analog sticks and buttons that 'flicker' by +1, -1 every time you poll; I added that distance test to ensure it was moved more than these devices flicker by. That way it won't rapidly assign anything when you first open the capture window.
The best part of all this, the drivers treat the buttons and sticks as exactly the same thing. I
could "guess" which it is by examining their states at first run, but that has one serious problem: what if the user was holding the button down when that test runs, or the controller is sitting upside down and the analog stick is forced to one direction? It would throw off calibration until restarting.
And ultimately, I don't even think there's much use in those buttons anyway. No SNES peripheral we support would benefit from an analog button (though it may work well with hypothetical Lasabirdie support :P)
It does sound like a nice feature for ruby::input, so maybe I'll add Input::calibrate() to do just that.
Fun stuff, huh? :)