Controllers with analog triggers won't configure properly
rilight last edited by rilight
I am having an issue where EmulationStation refuses to configure the analog triggers on my SF30 Pro. I believe this is because the resting position is improperly reported as a negative value instead of 0. Here are my jstest values:
$ jstest /dev/input/js0 Driver version is 2.1.0. Joystick (8Bitdo SF30 Pro) has 8 axes (X, Y, Z, Rx, Ry, Rz, Hat0X, Hat0Y) and 10 buttons (BtnA, BtnB, BtnC, BtnX, BtnY, BtnZ, BtnTL, BtnTR, BtnTL2, BtnTR2). Testing ... (interrupt to exit) Axes: 0: 0 1: 0 2:-32767 3: 0 4: 0 5:-32767 6: 0 7: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off
If anyone has ideas on how to patch EmulationStation so that it properly recognizes the inputs, I would greatly appreciate it. I am willing to make a pull request in order to fix this, but I'm not sure where to start or if this is actually the problem I think it is. Thank you.
Please add some more info about your system, as detailed in https://retropie.org.uk/forum/topic/3/read-this-first.
How is your gamepad connected: USB/Bluetooth ?
My apologies for not including the system info:
Pi Model or other hardware: 4B
Power Supply used: Official Raspberry Pi Foundation Raspberry Pi 4 USB-C power supply
RetroPie Version Used: 4.6
Built From: retropie-buster-4.6-rpi4.img
USB Devices connected: N/A
Controller used: 8BitDo SF30 Pro (Firmware version 1.34)
Error messages received: N/A
Verbose log: N/A (Does the jstest log count?)
Guide used: N/A
Attachment of config files: N/A
How to replicate the problem: Connect an SF30 Pro via Bluetooth in XInput mode and attempt to map the controls in EmulationStation. The left and right trigger buttons will not be recognized.
When using the USB connection, the
xpaddriver would be used for XInput/Xbox type controllers and the shoulder triggers would register as buttons as instead of axis. With Bluetooth, this doesn't apply and it looks like the negative axis movement reported for them are filtered out by EmulationStation's input configuration (here).
Now, what you could do, without modifying EmulationStation
- install the
xpadneodriver and see if the triggers are recognized. You'll have to re-pair and re-configure the input again.
- add the L2/R2 triggers manually to RetroArch's configuration file, based on this configuration file. You only need to add the
input_r2_axis- but in the RetroArchs repository they're bound
+axis<X>, you're probably going to switch the direction and see if it works in-game. If it doesn't, then this might be the reason why the ES configuration ignores them.
jscaland correct the trigger axis to repor the correct values so they'd work from 0 to +32767 instead. That might be the correct solution if the gamepad's firmware is not correctly reporting those values.
- install the
I installed xpadneo, removed my controller, completely rebooted, re-paired and attempted to configure the input again. It still didn't recognize my triggers. I skipped the manual RetroArch configuration for now since I wasn't quite sure what to do and I wanted to try jscal first. I used it to calibrate the controller, but that also didn't change anything—the controller still reports negative values at resting position. At this point I feel like fixing EmulationStation to actually recognize the controller would be the nicest option, especially since it would prevent the issue for anyone else using the same or similar controllers going forward.
skipped the manual RetroArch configuration for now since I wasn't quite sure what to do
Just configure the controller in ES, ignoring the shoulder triggers, then open the generated
\\retropie\configs\all\retroarch-joypadsand add 2 lines for
-5respectively. See if that works.
At this point I feel like fixing EmulationStation to actually recognize the controller would be the nicest option
There might be a proper reason why this configuration is filtered, I would suggest first to test the with a modified RetroArch auto-configuration profile and see if it works.
My bad, I didn't understand the reason for trying it that way. I'll check and report back.
Setting the axes to -2 and -5 didn't work. However, setting them to +2 and +5 as in the example configuration seems to work in-game.
So, what do you think this means in terms of EmulationStation not recognizing the inputs / what could be done to fix the problem?
Looking at the code in ES that filters out the controls, I think it's doing the right thing - if the exception wouldn't have been made, the resulting configuration would be
input_l2_axis = -2 input_r2_axis = -5
which is not a working configuration, as you discovered. I'm not familiar with that part of the code, but I assume this must have been the reason the trigger axis configuration is ignored.
That makes sense, I'm just wondering if there's a way to fix it so that it recognizes the correct axes. When the button is pressed down, it registers as the positive axis. The issue is that on return, it overshoots to the negative position instead of resting at 0. Instead of filtering out negative axes entirely, would it be possible to test for this kind of situation? It seems like multiple controllers unfortunately violate the SDL specification in the same way.
When the button is pressed down, it registers as the positive axis. The issue is that on return, it overshoots to the negative position instead of resting at 0. Instead of filtering out negative axes entirely, would it be possible to test for this kind of situation?
The problem with mapping the triggers is discussed in the issue that started this. It doesn't seem there is a reliable way to test for this situation and choosing the negative axis as a result breaks RetroArch
Since we can't set the axis number without polarity in mapping configuration, we have to choose either the negative or positive pole. Choosing the positive pole means that a firm press is needed, but the negative pole will cause triggers to be too sensitive. I chose the positive pole to keep it in line with the default PS3 controller mapping seen in software such as Kodi.
If there was a way to calibrate the axes to normalize the range from 0-32767 at a driver level, we could avoid this issue, but I'm not aware of a way to do it using the available evdev userspace tools.
rilight last edited by rilight
Ah right, that makes sense reading back over it. In that case, I'll make a PR to whitelist the SDL ID of the SF30 Pro in XInput mode if that would work. Thanks for the help and sorry for my apparent inability to read 😅