(Input) Proper analog trigger support

[Shoegzer]

From this issue, RA doesn't appear to support analog triggers properly, at least in linux. Hopefully with this fixed, cores such as reicast and other future cores making use of such inputs will function as they should.

Updated with details: In linux, attempting to set L2 and R2 within the RA GUI results in inproper digital values (axes 6 and 7 in my case) rather than proper analog values (axes +2 and +5 in my case). Manually editing retroarch.cfg to add the proper values will work, however this is counter-intuitive and not everyone would know to do that. All other details are in the upper part of this thread.

@hiddenasbestos realizing you're probably the best person on the team for this, if you could find some time to look into adding such support, I can help you test whatever you'd need. I currently have a test Intel Kaby Lake-based system with kernel 4.15 and ds4 pads, and can compile RA as needed. Thanks very much.

[hiddenasbestos]

I'm not sure I'm the best person to fix this but perhaps we can pool knowledge.
The relevant lines of code are:

input/drivers/* -> function xxx_input_state, e.g. udev_input_state

• If the core requests RETRO_DEVICE_ANALOG calls out to input_joypad_analog

input/input_driver.c -> function input_joypad_analog

• This has a special case for requesting analog data from buttons.
• Calls out to const input_device_driver_t *drv -> axis function, takes absolute and returns it.

To debug this on the faulty platform (I can't), put a printf to log the value of res in input_joypad_analog
res = abs( drv->axis( joypad_info.joy_idx, axis ) );

The value should always be from 0 to 0x7FFF (+32767), just like the analogue sticks. If the driver is returning weird values, we're past the point of being able to do something about it at this stage - it's a driver bug to report out of range or compressed values.

ps. XInput triggers work great for me, FWIW

[Shoegzer]

Thanks so much. I added the printf at the very bottom of the input_joypad_analog function (right above "return res;"). I observed that the values thrown to terminal were constant at "0" unless I pushed either the left or right trigger, in which case the corresponding value immediately jumped to "32767". So they are registering, and within the expected range, just not treated as analog for some reason. Note that the values returned for the left and right joysticks (not triggers) are reported properly as analog, as they slowly change values up to 32767 as the joystick is pushed left or right slowly.

BTW, I think a good ingame test is in Daytona USA's "Analog Calibration" section - if you slowly push "Gas" (default right trigger) I'm pretty sure it should show the needle slowly moving from left to right. In my case, it goes immediately from far-left to far-right, as consistent with the printf test above. Try it yourself when you have a chance and let me know what you get in Xinput.

Also, in case it matters: Dolphin emulator's input settings applet lets you see analog trigger values as the triggers are pressed. In that applet, I can see the range slowly increasing when I slowly press the triggers, as it should.

[hiddenasbestos]

Ok, sounds like the common input code isn't getting any analog data back for the trigger and is falling back to digital input, as designed (in case you mapped a face button to an expected analog input)

Might wanna verify that by moving your printf to right after res = abs( drv->axis( joypad_info.joy_idx, axis ) ); because we need to know it's the call to drv->axis that's making the res = 0 happen.

Based on what you've told me, I'm wondering about what's happening deeper in the udev code. In the file input/drivers_joypad/udev_joypad.c in function udev_joypad_axis. I'd be very curious what's going on in there:

• Does this function actually get called for the triggers?
• If so, does it return 0 after if joyaxis == AXIS_NONE ?
• What are the value of AXIS_NEG_GET(joyaxis) and AXIS_POS_GET(joyaxis) for each trigger?
• What are the values in the pad->axes array, specifically the AXIS_NEG_GET and AXIS_POS_GET elements? Are these analog?
• What is the value of 'val' before it's clamped to 0 (in both cases)?

Also if that proves to be a bust - my next port of call would be udev_joypad_poll in the same file.

• In 'case EV_ABS', does the mechanism to store values in pad->axes[axis] work? e.g. what is pad->axes_bind[code]
• When it does switch (type) and finds EV_KEY or EV_ABS - what other types exist?

Past that I'm out of ideas...

DISCLAIMER: I've never looked at this udev code in my life before now, if someone else wrote this and knows more about it feel free to chip in, I'm just commenting using my general debugging experience.

[Shoegzer]

Okay, I moved the code, so now I have:

res = abs( drv->axis( joypad_info.joy_idx, axis ) );
printf ("Res: %d\n", res);

Now when I launch a game, all inputs report "0" whether buttons/triggers are pressed or not. Hopefully that helps.

Incidentally, since you mentioned udev code - not sure if it matters but I also changed the "Joypad Driver" in the RA UI from "udev" to "sdl2" and restarted, but I still get the same digital trigger behavior.

You ask some good questions, for example it would certainly be great to know whether the udev_joypad_axis function gets called at all for triggers. I'm happy to try out any other changes to the code you may suggest to get some answers together for us - e.g. I could printf some more test indicator values in certain spots to see if specific functions are being called when input occurs etc. Otherwise maybe @twinaphex knows or can find the person/people who wrote the original input code to provide more direct responses.

[hiddenasbestos]

If all inputs report 0, that means reicast's requests for triggers are calling the driver code and getting no analogue data. This fits what what you're describing but I can't explain why the driver is acting like that.

btw. you should be able to debug all my questions with printfs in the UDEV code. But if SDL2 isn't working that's sounding like maybe a config error? Have you tried binding a thumbstick axis to RetroPad's L2 / R2 and seeing what happens?

I'm going to take a step back at this point.

[Shoegzer]

Regarding debugging, I wouldn't know where in the udev code to put the printfs but if you give me an idea of where you'd like them, I'll certainly do that and provide results.

As you suggested I set the right thumbstick X axis to RetroPad's L2 / R2 - now the code with the printf in the new location returns values from 0 to 32767 properly, and Daytona's analog calibration tool works fine with the thumbstick. Otherwise I think my configuration is not a factor but maybe @mickski56 could comment here as well, as he encountered the same issue.

[hiddenasbestos]

printf's in the udev code: go crazy and pepper them all over!

Sounds like your controller's triggers aren't being read by the analog code. Definitely sounds like a bug in udev / config / linux.

[Shoegzer]

Hmm.. well it doesn't appear to be a bug in udev / linux, triggers are known to be working fine for many other games/emulators such as Dolphin (as I mentioned) that use analog triggers.

Update:

I have a linux graphical input tool called "jstest" which shows all axes and how they respond to input. This tool shows that the D-Pad is mapped to axes 6 and 7; whereas the L2 / R2 triggers are mapped to axes 2 and 5 respectively. With this tool, the analog triggers behave as they should, with values that slowly move as you slowly press them.

Out of curiosity I ran Dolphin and RA controller setups side-by-side, and I noticed that with Dolphin, it sets the D-Pad to axes 6 and 7, and sets the L2 / R2 analog triggers to axes 2 and 5, respectively - this matches my jstest tool, and as mentioned before, triggers behave as they should here too. However, RA sets the D-Pad to "Hat #0 up/down/left/right" and analog triggers to axes 6 and 7 (i.e. the D-Pad axes according to both jstest and Dolphin). So it appears that for some reason, RA wants to treat the triggers as if they're digital D-Pad axes.

[Shoegzer]

2nd Update:

I fixed it! Well, at least in the config. As I stated above, it appears that the RA UI doesn't set the analog triggers properly. However, you can manually edit the retroarch.cfg file to set them properly, as follows:

1. Determine what axes are being reported by the OS for L2 and R2 (in my case they are axes 2 and 5 respectively).

2. Manually edit the $home/.config/retroarch.cfg file. Using my example axes above, you'd change the following lines to:

input_player1_l2_axis = "+2"
input_player1_r2_axis = "+5"

3. Save and restart RA. Analog triggers should now work properly. @mickski56 when you have a chance, please confirm this works for you too.

Of course, a proper fix will involve fixing whatever code sets these values in the RA UI, so the above hack won't be necessary. The RA UI code to set other analog values seems to be fine, so I'm hoping this isn't too tricky to track down, but again I'm happy to help wherever I can.

[hiddenasbestos]

Hey @twinaphex , over to you :)

[mickski56]

@Shoegzer annoyingly I'm still getting 50% dead zones on my triggers. My axes are mapped the same as yours. Printf's in input_driver.c print out values in the range 0 to 32676 but only for 50% to 100% trigger.
Further investigation is required on my part. As an aside be careful with jstest it uses the old linux joystick (/dev/input/js*) interface whereas udev/evdev uses the newer event (/dev/input/event*) interface. jstest will report axis and button numbers correctly tho.

The "proper fix" is probably updates in retroarch-joypad-autoconfig, not having any overridden bindings in retroarch.cfg and using per core/game overides if you need to swap buttons around. Some of the latest autoconfigs have triggers enabled some don't. Tho if you have both triggers and buttons both enabled for the same trigger in the *controller.cfg you get buttons.

[Shoegzer]

@mickski56 are you sure the dead zone is an RA issue? How do you know it's exactly 50% or are you estimating? I've also found that in both Dolphin (input menu) and RA (reicast/Daytona calibration menu), when I press the trigger slowly, it doesn't actually register until about 10-15% of the way pressed (and changing the analog dead zone setting in RA's input menu doesn't seem to have any effect). Perhaps this is just the design of the hardware in both of our cases?

In any event you are quite right about jstest, I just don't know of an equivalent udev/evdev tool unless you do?

By the way, should I assume that you could set your analog triggers in RA's menu without my manual fix above? I still think there's an issue with the code somewhere in RA, as I can set the other analog sticks just fine, and I haven't overridden anything to my knowledge.

[mickski56]

@Shoegzer pretty sure it's an RA issue.
But first your second point about udev/evdev test tools, use evtest /dev/input/event* to see output like jstest (also works with event mice and keyboards), use evdev-joystick from linux console tools to calibrate, set deadzones and signal noise reduction on event(udev) joypads. Tho you will have to write a udev rule if you want your settings to stick. "evdev-joystick -e /dev/input/event* -f 1" is great to stop axes jittering so you can see the output of evtest.

Back to RA, using evtest I can tell where my triggers start to work it's around 5-10 % & I can also see where 50% is. Stand alone reicast also works how I would expect i.e. 5% to 100% on the triggers.
I cheated a bit by editing my controllers autoconfig file, as i said some autoconfig files have triggers enabled some don't.

I'm going to try Dolphin (input menu) just for a double check.
Tried Dolphin stand alone it initially picks the trigger up as button then with the trigger pressed a bit it picks it up as an axis. Displaying "Axis 2-+" for the left trigger. Displaying full range analog trigger movement.

btw if i change input_player1_l2_axis = "+2" to input_player1_l2_axis = "-2" i get the trigger working ~10% - 100% (full range) but it's inverted, i.e.0% is interpreted as full press. No it doesen't with some printf's in input_driver.c and sdl_joypad.c I can see this is not the case, it's just the way my triggers work making it less noticable when 50% - 100% is ignored. don't try this it stops the front end from working (don't plug the joystick in until you're in the game calibration page)

If you have the command line tool jstest, can you run "jstest /dev/input/js0" and tell me what the minimum value for the trigger axis is (trigger at 0%) please.

[mickski56]

With the above mentioned printf's I can summarize the problem as follows. The low level driver in this case sdl_joystick.c reports trigger movement as -32767 -- 0 -- 32767 (which is what you want from a stick, but not a trigger). input_driver.c gets an axis bind by various means but they are always specified as half an axis (0 -- 32767 or 0 -- -32767) so 50% of the trigger movement is not bound and never used.

Can anyone confirm that trigger axes report this way for them on linux dualshock3 or xbox360.
kernel 4.14.52 also what does a dualshock4 report ?

[hiddenasbestos]

The low level driver in this case sdl_joystick.c reports trigger movement as -32767 -- 0 -- 32767

Does this mean:

hands off -> 0
left trigger full, right trigger released -> -32767
right trigger full, left trigger released -> +32767
both triggers pulled -> 0

360 pad works like this on Windows in DirectInput mode and it's unhelpful! Which is why you need XInput to use triggers properly (as Xinput reports 0->255 for both triggers independently)