Here is a way to select joystick for players 1-4 (global or emu specific)

BuZz

Just a heads up - I have implemented joypad selection into the configuration editor now. I am ordering by device path, which seems to match how retroarch sees them in udev mode (at least from my initial testing)

meleu

@BuZz
Unfortunately it doesn't works as expected here...
In my old laptop, Linux always get a non-joystick device as js0. It is the ST LIS3LV02DL Accelerometer (honestly, I didn't even know it exist an accelerometer here!). Neither RetroArch nor SDL recognize it as a joystick. So, my "real" joysticks start from js1 with index 0.

BTW: Because of this accelerometer at js0 I was unable to use joysticks in retropie_setup. Thanks for implementing that "feature" on __joy2key_dev! Now I can set another device. :-)

BuZz

Thanks - I think I just need to perhaps ignore it based on another device flag, but in the case of both of my setups it works (for now)

meleu

@BuZz
Another improvement suggestion:
After setting the controllers for, let's say, NES, I go to the ...nes/retroarch.cfg and the input_playerN_joypad_index variables are after that #include for global configs. Which means that the global config allways takes precedence over the specific config.

BTW again: your configedit.sh made me realize the usefulness of inifuncs.sh. Really cool!

meleu

@BuZz
Improvement suggestion again...
I was struggling to find a way to check if player1 has a valid index right before start RetroArch. This is useful because if RetroArch starts with an invalid player1 index AND there is no keyboard, then there is no way to access RGUI. And if the RetroPie is NOT accessible via SSH, the user can't exit RetroArch. Unplug the power supply is the only solution, as far as I know.

I know that the best way is implement this verification in runcommand.sh, but I didn't want to change an "official" script. Other solutions that I found are very inelegant for my taste: edit es_systems.cfg to call a verification script before runcommand; create other entries in systems emulator.cfg to call verification script before retroarch...

Since you are the man-who-own-that-file, if you think it's usefull, maybe you can implement such feature...

I was thinking in something like this pseudo-code with a touch of bash (not taking care of precedences for a while):

if "$command" has a 'retroarch.cfg' string; then
    if 'retroarch.cfg' file has the 'input_player1_joypad_index' string; then
        p1_index = input_player1_joypad_index
        p1_file = "retroarch.cfg"
    elif 'retroarch.cfg' file has '#include ...' entries; then
        for include in include_entry1 include_entry2 etc... ; do
            if "$include" file has the 'input_player1_joypad_index' string; then
                p1_index = input_player1_joypad_index
                p1_file = "$include"
                break
            fi
        done

    if "$p1_index" is empty; then
        # it's OK. RetroArch will set it to zero automatically
        return 0
    fi

    if "$p1_index" is NOT a valid joystick index; then
        echo "warning: setting input_player1_joypad_index to 0"
        set 'input_player1_joypad_index' to '0' in "$p1_file"
    fi
fi

BuZz

@meleu maybe for a later version :)

BuZz

@meleu said in Here is a way to select input for RetroArch players 1-4:

@BuZz
Another improvement suggestion:
After setting the controllers for, let's say, NES, I go to the ...nes/retroarch.cfg and the input_playerN_joypad_index variables are after that #include for global configs. Which means that the global config allways takes precedence over the specific config.

BTW again: your configedit.sh made me realize the usefulness of inifuncs.sh. Really cool!

They should go before the include. I'll check

meleu

@BuZz said in Here is a way to select input for RetroArch players 1-4:

@meleu maybe for a later version :)

Maybe a custom_command variable to be placed at ...configs/all/runcommand.cfg to let the user execute something before start the emulator...

please

BuZz

you can now place scripts at /opt/retropie/configs/all/runcommand-onstart.sh and /opt/retropie/configs/all/runcommand-onend.sh

BuZz

Please can you give me the output of udevadm info /dev/input/js0 (the device which isn't really a joystick on your setup.

meleu

@BuZz said in Here is a way to select input for RetroArch players 1-4:

you can now place scripts at /opt/retropie/configs/all/runcommand-onstart.sh and /opt/retropie/configs/all/runcommand-onend.sh

Wow! Those Puss'in'Boots eyes are really useful! Thanks man!

@BuZz said in Here is a way to select input for RetroArch players 1-4:

Please can you give me the output of udevadm info /dev/input/js0 (the device which isn't really a joystick on your setup.

Here it go:

[prompt]$ udevadm info /dev/input/js0
P: /devices/platform/lis3lv02d/input/input10/js0
N: input/js0
E: DEVNAME=/dev/input/js0
E: DEVPATH=/devices/platform/lis3lv02d/input/input10/js0
E: ID_INPUT=1
E: ID_INPUT_ACCELEROMETER=1
E: ID_PATH=platform-lis3lv02d
E: ID_PATH_TAG=platform-lis3lv02d
E: MAJOR=13
E: MINOR=0
E: SUBSYSTEM=input
E: USEC_INITIALIZED=233075

BuZz

I have pushed an update that should ignore this device now in the config editor (hopefully).

meleu

@BuZz said in Here is a way to select input for RetroArch players 1-4:

I have pushed an update that should ignore this device now in the config editor (hopefully).

Yeah! Worked here!

I've noticed a little issue... My joystick_selection.sh utility puts an #include at the beggining of the global retroarch.cfg, then its users won't see the changes made by the configedit.sh.

I'm gonna change my joystick_selection.sh to do the same way configedit.sh does: change input_playerN_joypad_index directly in retroarch.cfg. Then both utilities can manage the same data harmoniously.

Later we have to think in a way to check the precedences...

meleu

@BuZz said in Here is a way to select input for RetroArch players 1-4:

@meleu said in Here is a way to select input for RetroArch players 1-4:

@BuZz
Another improvement suggestion:
After setting the controllers for, let's say, NES, I go to the ...nes/retroarch.cfg and the input_playerN_joypad_index variables are after that #include for global configs. Which means that the global config allways takes precedence over the specific config.

BTW again: your configedit.sh made me realize the usefulness of inifuncs.sh. Really cool!

They should go before the include. I'll check

I think I know what hapenned here...

When the system specific retroarch.cfg have no input_playerN_joypad_index entry, the iniSet (actually iniProcess at this line) puts it at the end of the file.

BuZz

It's a bug for a few custom configedit functions. Will sort.

BuZz

should be fixed.

skrapps914

i have a weird issue with this. or at least i think it is this script. whenever i install it, my gba emulator stops working. it wont load any games. i only believe its this giving lr-gpsp an issue, because ive installed it, and gba wont load, i formatted the card, gba worked again, installed the controller script again, and gba stopped working. i checked the runcommand log for the error report, but the runcommand log is blank.

meleu

@skrapps914
Thanks for your feedback. It gave me the idea to create an uninstall procedure.

I can't see how the script can do this. But if you want to disable it to check if it really is the reason, you can delete the #include line at the beggining of /opt/retropie/configs/all/retroarch.cfg.

skrapps914

@meleu said in Here is a way to select input for RetroArch players 1-4:

@skrapps914
Thanks for your feedback. It gave me the idea to create an uninstall procedure.

I can't see how the script can do this. But if you want to disable it to check if it really is the reason, you can delete the #include line at the beggining of /opt/retropie/configs/all/retroarch.cfg.

thanks for your reply and help. I went and removed the code, and lr-gpsp still wont work, perhaps it was something else that's causing it, and not this as suspected. i'm stuck without a clue as to why it will work, and then stop working once i installed the controller scrip though. maybe there was something else updating in the background, like the retropie script or something... i'm gonna format the card again, and try again, see if i can track it down

edmaul69

@skrapps914 why reformat? Did you try going into retro-pie setup and reinstall the emulator? Which emulator are you using. Have you tried the other emulator?