Inconsistent mapping of triggers for Dolphin script

GoldenPalazzo

Sorry if probably the correct category was Help and Support.

I am trying to write a script that automates the configuration of Dolphin standalone in order to not to use too much mouse and keyboard and have more like a "plug and play" feeling, since the standalone version is better than the libretro core in every way besides the mapping.
The script tries to parse es_input.cfg and remap all Wii keybinds according to the SDL mapping of the gamepad.
Using SDL_JOYSTICK_HIDAPI=0 I am able to get a consistent SDL mapping matching with the ES configuration except for the triggers.
Taking as example my DS4 gamepad, SDL maps both axes and buttons to the triggers, but because of the filterTrigger function in ES, the configuration only takes buttons for the triggers.
Trying to get the bindings from SDL_GameControllerGetBindForAxis seems impossible, since it always uses the HIDAPI mappings.
Is there another way I can get the user gamepad mappings?

mitu

@GoldenPalazzo said in Inconsistent mapping of triggers for Dolphin script:

Is there another way I can get the user gamepad mappings?

The only method to get the user chosen mapping is via the ES input configuration. When the input configuration is saved, there's an es_temporaryinput.cfg file that is written, from which the configuration in es_input.cfg is generated. You're perhaps familiar with this if you studied how mappings for other emulators are generated (RetroArch, Mupen64plus, etc.). For ES, there's not much difference between the 2 files as far as the input config is concerned apart for the hotkey enable mapping, which is not present in es_input.cfg, but used for other emulators' mapping.

Using a generinc mapping akin to the one used by SDL's GameControllerDB is not really correct since the user may choose different values than the 'canonical' mapping envisioned by SDL, plus there are generic controller names shared by different controllers which can cause conflicts (i.e. the DragonRise... arcade controllers which offer different configuration but not only they have the same name, but also the same VendorId/ProductID).

Taking as example my DS4 gamepad, SDL maps both axes and buttons to the triggers, but because of the filterTrigger function in ES, the configuration only takes buttons for the triggers.

I think that applies to triggers/push on the 2 analog joysticks and the filter was added so that the user doesn't accidentally maps the joystick axis to the trigger, which is probably not what they want.

GoldenPalazzo

@mitu said in Inconsistent mapping of triggers for Dolphin script:

Using a generinc mapping akin to the one used by SDL's GameControllerDB is not really correct since the user may choose different values than the 'canonical' mapping envisioned by SDL, plus there are generic controller names shared by different controllers which can cause conflicts (i.e. the DragonRise... arcade controllers which offer different configuration but not only they have the same name, but also the same VendorId/ProductID).

That's why I bothered that much trying to parse the user configuration of EmulationStation and wanted to know how the hell I could get the corresponding digital buttons to the triggers of gamepads, however reading more of the source code made me discover something.

@mitu said in Inconsistent mapping of triggers for Dolphin script:

I think that applies to triggers/push on the 2 analog joysticks and the filter was added so that the user doesn't accidentally maps the joystick axis to the trigger, which is probably not what they want.

Looking at GuiInputConfig.cpp, the filterTrigger function is explicitly called only for triggers. However the comment at row 355 states // digital triggers are unwanted. So the intended behavior is to actually discard the digital triggers and only take analog triggers when possible.
However the only gamepad names that were tested are "PLAYSTATION", "PS3 Ga", "PS(R) Ga", and the GUID of "030000006b1400000209000011010000", which is a Bigben PS3 gamepad. My Dualshock 4 (and since it's official, I think all Dualshocks should behave the same) is actually called "Sony Interactive Entertainment Wireless Gamepad" and didn't trigger the filter routine.
Moreover, the recently released Anbernic RG P01 also isn't contemplated between the 6-axis gamepads that also have a digital trigger firing when pressing it.
So I basically added these two exceptions to the source and everything worked fine.
I hope my edit in the source actually makes sense.

mitu

@GoldenPalazzo said in Inconsistent mapping of triggers for Dolphin script:

I hope my edit in the source actually makes sense.

I'm not sure. I also have a DS4 and I didn't have an issue mapping all the buttons/axis/etc. with RetroPie's EmulationStation fork, so I don't see any edits being necessary (?).

GoldenPalazzo

@mitu when you try to map the Dualshock 4, do you get "Button 6" and "Button 7" when mapping triggers or "Axis 2+" and "Axis 5+"?

mitu

@GoldenPalazzo said in Inconsistent mapping of triggers for Dolphin script:

@mitu when you try to map the Dualshock 4, do you get "Button 6" and "Button 7" when mapping triggers or "Axis 2+" and "Axis 5+"?

I get the following config, which I guess it means buttons 6 and 7:

<inputList>
        <inputConfig type="joystick" deviceName="Sony Interactive Entertainment Wireless Controller" vendorId="1356" productId="2508" deviceGUID="0300d0424c050000cc09000011810000">
                <input name="a" type="button" id="1" value="1" />
                <input name="b" type="button" id="0" value="1" />
                <input name="down" type="hat" id="0" value="4" />
                <input name="hotkeyenable" type="button" id="10" value="1" />
                <input name="left" type="hat" id="0" value="8" />
                <input name="leftanalogdown" type="axis" id="1" value="1" />
                <input name="leftanalogleft" type="axis" id="0" value="-1" />
                <input name="leftanalogright" type="axis" id="0" value="1" />
                <input name="leftanalogup" type="axis" id="1" value="-1" />
                <input name="leftshoulder" type="button" id="4" value="1" />
                <input name="leftthumb" type="button" id="11" value="1" />
                <input name="lefttrigger" type="button" id="6" value="1" />
                <input name="right" type="hat" id="0" value="2" />
                <input name="rightanalogdown" type="axis" id="4" value="1" />
                <input name="rightanalogleft" type="axis" id="3" value="-1" />
                <input name="rightanalogright" type="axis" id="3" value="1" />
                <input name="rightanalogup" type="axis" id="4" value="-1" />
                <input name="rightshoulder" type="button" id="5" value="1" />
                <input name="rightthumb" type="button" id="12" value="1" />
                <input name="righttrigger" type="button" id="7" value="1" />
                <input name="select" type="button" id="8" value="1" />
                <input name="start" type="button" id="9" value="1" />
                <input name="up" type="hat" id="0" value="1" />
                <input name="x" type="button" id="2" value="1" />
                <input name="y" type="button" id="3" value="1" />
        </inputConfig>
</inputList>

GoldenPalazzo

@mitu standing to the comment in the script that I mentioned earlier

@GoldenPalazzo said in Inconsistent mapping of triggers for Dolphin script:

Looking at GuiInputConfig.cpp, the filterTrigger function is explicitly called only for triggers. However the comment at row 355 states // digital triggers are unwanted.

having buttons instead of triggers is unwanted behaviour. The only reason it went unnoticed it's because digital triggers also work in RetroArch. I just stumbled upon it because I wanted to make a script for Dolphin and had a naming mismatch between EmulationStation inputs and SDL mappings.

mitu

@GoldenPalazzo If I test the joystick with jstest the triggers and shoulder buttons are reported as buttons and they react with on when pressed.

If I use 'testjoystick' from SDL to test, they appear as axis, but if I disable SDL's HIDAPI driver, they appear as buttons. Since ES disables HIDAPI internally, so I think the mapping I posted is correct. I think that if you enable or inhibit the HIDAPI suppression in ES, then you'd get the 'right' (i.e axis) mapping for the shoulder triggers, without any further patches necessary.

GoldenPalazzo

@mitu with HIDAPI enabled, both my triggers are registered as axis 4 and 5, disabling it gives BOTH axis and buttons. As you suggest, a way of solving this double keys issue was to enable the HIDAPI, but discarded it since I saw the reason you disabled it and seemed pretty valid. Also the Anbernic RG P01 keeps the digital and analog triggers even in HIDAPI=1, so it would just solve the issue for DS4 gamepads.
I just added the DS4 to the list of the exceptions since it seems that the behavior you wanted was to ignore the digital triggers and only get the analog ones, correct me if I'm wrong.

mitu

@GoldenPalazzo said in Inconsistent mapping of triggers for Dolphin script:

I just added the DS4 to the list of the exceptions since it seems that the behavior you wanted was to ignore the digital triggers and only get the analog ones, correct me if I'm wrong.

The filter function was not added by me. With your modifications, would the resulting input mapping be different and - possibly - break RetroArch generated input profile ?

GoldenPalazzo

@mitu it shouldn't. Gamepads that don't fire digital events with their triggers like the Logitech F710 still work in RetroArch.
However I ran a test with my edited EmulationStation, remapped the DS4 and let ES reconfigure the gamepad for RetroArch
Here's ~/.emulationstation/es_temporaryinput.cfg, note the analog triggers being set up correctly

<?xml version="1.0"?>
<inputList>
        <inputConfig type="joystick" deviceName="Sony Interactive Entertainment Wireless Controller" vendorId="1356" productId="2508" deviceGUID="0300d0424c050000cc09000011810000">
                <input name="a" type="button" id="1" value="1" />
                <input name="b" type="button" id="0" value="1" />
                <input name="down" type="hat" id="0" value="4" />
                <input name="hotkeyenable" type="button" id="10" value="1" />
                <input name="left" type="hat" id="0" value="8" />
                <input name="leftanalogdown" type="axis" id="1" value="1" />
                <input name="leftanalogleft" type="axis" id="0" value="-1" />
                <input name="leftanalogright" type="axis" id="0" value="1" />
                <input name="leftanalogup" type="axis" id="1" value="-1" />
                <input name="leftshoulder" type="button" id="4" value="1" />
                <input name="leftthumb" type="button" id="11" value="1" />
                <input name="lefttrigger" type="axis" id="2" value="1" />
                <input name="right" type="hat" id="0" value="2" />
                <input name="rightanalogdown" type="axis" id="4" value="1" />
                <input name="rightanalogleft" type="axis" id="3" value="-1" />
                <input name="rightanalogright" type="axis" id="3" value="1" />
                <input name="rightanalogup" type="axis" id="4" value="-1" />
                <input name="rightshoulder" type="button" id="5" value="1" />
                <input name="rightthumb" type="button" id="12" value="1" />
                <input name="righttrigger" type="axis" id="5" value="1" />
                <input name="select" type="button" id="8" value="1" />
                <input name="start" type="button" id="9" value="1" />
                <input name="up" type="hat" id="0" value="1" />
                <input name="x" type="button" id="2" value="1" />
                <input name="y" type="button" id="3" value="1" />
        </inputConfig>
</inputList>

and here's the autoconfiguration at /opt/retropie/configs/all/retroarch/autoconfig/Sony\ Interactive\ Entertainment\ Wireless\ Controller.cfg

input_device = "Sony Interactive Entertainment Wireless Controller"
input_driver = "udev"
input_vendor_id = "1356"
input_product_id = "2508"
input_r_y_plus_axis = "+4"
input_r_y_plus_axis_label = "Right Analog Down"
input_left_btn = "h0left"
input_left_btn_label = "D-Pad Left"
input_state_slot_decrease_btn = "h0left"
input_r_x_minus_axis = "-3"
input_r_x_minus_axis_label = "Right Analog Left"
input_right_btn = "h0right"
input_right_btn_label = "D-Pad Right"
input_state_slot_increase_btn = "h0right"
input_r_btn = "5"
input_r_btn_label = "R1"
input_save_state_btn = "5"
input_down_btn = "h0down"
input_down_btn_label = "D-Pad Down"
input_r_y_minus_axis = "-4"
input_r_y_minus_axis_label = "Right Analog Up"
input_l_btn = "4"
input_l_btn_label = "L1"
input_load_state_btn = "4"
input_r_x_plus_axis = "+3"
input_r_x_plus_axis_label = "Right Analog Right"
input_y_btn = "3"
input_y_btn_label = "Square"
input_x_btn = "2"
input_x_btn_label = "Triangle"
input_menu_toggle_btn = "2"
input_b_btn = "0"
input_b_btn_label = "Cross"
input_reset_btn = "0"
input_a_btn = "1"
input_a_btn_label = "Circle"
input_up_btn = "h0up"
input_up_btn_label = "D-Pad Up"
input_select_btn = "8"
input_select_btn_label = "Share"
input_l3_btn = "11"
input_l3_btn_label = "L3"
input_start_btn = "9"
input_start_btn_label = "Options"
input_exit_emulator_btn = "9"
input_l_x_plus_axis = "+0"
input_l_x_plus_axis_label = "Left Analog Right"
input_l_y_minus_axis = "-1"
input_l_y_minus_axis_label = "Left Analog Up"
input_enable_hotkey_btn = "10"
input_l2_axis = "+2"
input_l2_axis_label = "L2"
input_r2_axis = "+5"
input_r2_axis_label = "R2"
input_l_y_plus_axis = "+1"
input_l_y_plus_axis_label = "Left Analog Down"
input_r3_btn = "12"
input_r3_btn_label = "R3"
input_l_x_minus_axis = "-0"
input_l_x_minus_axis_label = "Left Analog Left"

and everything is mapped correctly.

@mitu said in Inconsistent mapping of triggers for Dolphin script:

would the resulting input mapping be different and - possibly - break RetroArch generated input profile ?

Different mapping? Probably yes because now it picks up the analog triggers as it should. So people would need to reconfigure all their gamepads in order to use the correct mapping.
Break configurations? Absolutely not, they are RetroArch compliant.

mitu

Yeah, seems reasonable, thanks for the comparison.

GoldenPalazzo

@mitu no problem, I also sent a PR if you want to review the code.
One last question if I'm not bothering you: why are the permanent and temporary configurations different? I mean that es_input.cfg and es_temporaryinput.cfg have different mapping names (for example "pageup" and "pagedown" instead of "leftshoulder" and "rightshoulder") and also excludes triggers from the configuration? I don't remember how I got a "full" es_input.cfg, but the immediate tests I did to check my code didn't get me a permanent config not even similar to yours, while the temporary one is the exact one I was trying to reproduce.

mitu

@GoldenPalazzo ES itself doesn't use all the inputs on a controller, hence the lack of some of the inputs in es_input.cfg while they're present in the temporary file. The temporary file is used to configure other applications (i.e. RetroArch) which may use those inputs (triggers, hotkey enable are sure to be used).

As for the naming difference, I think at some point the shoulder buttons got renamed (in ES's config, not the generated one, which is used for more than ES) to the keys corresponding to the action associated in ES's gamelist (page up/down).

GoldenPalazzo

@mitu said in Inconsistent mapping of triggers for Dolphin script:

<input name="righttrigger" type="button" id="7" value="1" />

@mitu how come you got all the inputs in your configuration? Were you referencing your temporary config or the full one?

mitu

@GoldenPalazzo said in Inconsistent mapping of triggers for Dolphin script:

Were you referencing your temporary config or the full one?

Yes, the temporary config.

sugarfree

I think @retropieuser555 has started something similar : https://github.com/RetroPie/RetroPie-Setup/pull/3969

GoldenPalazzo

@sugarfree yeah, it's kinda what I had in mind.
I'm not very practical about shell scripting, however from what I could grasp it seems that they're creating a whole new mapping script to create evdev mappings.
Since I was trying to create a Python script that was going to be launched when a ROM had been selected and didn't want to add more dependencies, I tried to use SDL2 as library in my script: however the naming a of the buttons are extremely different from what you could get from evdev and had to make an intermediary translator between evdev and Dolphin passing through the SDL mapping of that gamepad.
Their solution is far more practical. However I think one of their bigger limits is that the script essentially creates a Dolphin profile for each gamepad, basically a 1:1 mapping between the gamepad and the GameCube controls. For the GameCube I think it's a pretty neat solution. Different matter is when you try to apply the same strategy when mapping a Wiimote: one profile isn't enough since you can have more peripherals setups on a Wii.
Two things I could think of are: making a profile for each possible setup (Wiimote, Wiimote+Nun chuck, Wiimote+Classic Gamepad etc...) and asking at each ROM load which profile should be loaded to each player, probably with a nice whiptail+joy2key TUI; or creating on the fly a configuration after asking which peripheral setup the player wants.