Please do not post a support request without first reading and following the advice in

XInput Controllers Not Working Correctly in RetroArch

  • Pi Model or other hardware: Raspberry Pi 3B
    Power Supply used: Official Raspberry Pi Universal Power Supply
    RetroPie Version Used: 4.4
    Built From: Pre-made SD Image on RetroPie website.
    USB Devices connected: Logitech F310 (In XInput Mode)
    Controller used: Logitech F310 (In XInput Mode)
    Log found in /dev/shm/runcommand.log:
    Emulator: All RetroArch Libretro Emulators

    First of all, I believe the issue is related to my previous topic below since it was an Xpad issue.

    I apologize if creating this new topic wasn't the correct thing to do, but it just seemed like I should make a new topic since that was related to the Xpad driver having an error when attempting to update, which is no longer the case.

    Now then, after updating RetroPie successfully, I remapped my Logitech F310 (In XInput Mode) to fix controls completely in EmulationStation, however, when attempting to play any game on any system with any RetroArch Libretro emulator, controls do not work properly.

    At first, when a game is launched, no controls work whatsoever. If I press buttons numerous times on the Logitech F310 (In XInput Mode), the controls will eventually respond. If I go into the RGUI, then I can't navigate or exit from the RGUI.

    I could easily circumvent this issue by switching my Logitech F310 to DirectInput Mode (I've already configured it to properly exit the emulators), but that's just ignoring what I believe to be a serious RetroPie issue that I felt needed to be reported.

    Thank you for your time.

  • Global Moderator

    Well, the docs recommend using the XInput mode, but anyway - can you try switching the input_method in the controller .cfg file from udev to sdl2 and see if it makes a difference ? The file should be in /opt/retropie/configs/all/retroarch-joypads/ and named after your controller.

  • @mitu Changing udev to sdl2 in /opt/retropie/configs/all/retroarch-joypads/ (True Path:/opt/retropie/configs/all/retroarch/autoconfig) changed nothing. Restarted the Raspberry Pi to make sure the change was completely recognized.

    Here is my Logitech Gamepad F310.cfg to make sure I edited the correct file.

    input_device = "Logitech Gamepad F310"
    input_driver = "sdl2"
    input_r_y_plus_axis = "+4"
    input_r_x_minus_axis = "-3"
    input_l_btn = "4"
    input_load_state_btn = "4"
    input_start_btn = "7"
    input_exit_emulator_btn = "7"
    input_r_y_minus_axis = "-4"
    input_down_btn = "h0down"
    input_l_x_plus_axis = "+0"
    input_r_btn = "5"
    input_save_state_btn = "5"
    input_right_btn = "h0right"
    input_state_slot_increase_btn = "h0right"
    input_select_btn = "6"
    input_left_btn = "h0left"
    input_state_slot_decrease_btn = "h0left"
    input_l2_axis = "-2"
    input_l3_btn = "9"
    input_l_y_minus_axis = "-1"
    input_up_btn = "h0up"
    input_a_btn = "1"
    input_b_btn = "0"
    input_reset_btn = "0"
    input_enable_hotkey_btn = "8"
    input_l_y_plus_axis = "+1"
    input_r2_axis = "-5"
    input_r3_btn = "10"
    input_x_btn = "3"
    input_menu_toggle_btn = "3"
    input_l_x_minus_axis = "-0"
    input_y_btn = "2"
    input_r_x_plus_axis = "+3"

    Also, here is the new log where I believe nothing has changed (RetroArch continues to use udev).

    Log found in /dev/shm/runcommand.log:

    After doing as I was told, I also tried changing udev to sdl2 in retroarch.cfg, which changed the udev mentions in the runcommand.log to sdl2 and caused all controller input to no longer respond: I promptly undid the change.

    Current retroarch.cfg:

  • Global Moderator

    @eckaji From the logfile it seems it's still using the udev driver to detect and configure the input

    [INFO] [autoconf]: selected configuration: /home/pi/.config/retroarch/autoconfig/Logitech Gamepad F310.cfg
    [INFO] [Joypad]: Found joypad driver: "udev".

  • @mitu Yeah, I could only get that to change by altering the udev in retroarch.cfg to sdl2. Here is the runcommand.log after doing just that.

    Log found in /dev/shm/runcommand.log:

    Changing the Logitech Gamepad F310.cfg entry's udev to sdl2 still seems to have done nothing.

  • Global Moderator

    @eckaji One thing I noticed in the new log file is that the device name is now reported as Logitech F310 Gamepad (XInput), while in previous logs was Logitech F310 Gamepad. In the new run, RA cannot find the .cfg file, while in the previous runs it could.
    Did you configure the gamepad in ES in XInput or DInput mode ?

  • I have the same controller, I setup in ES when in Xinput mode and it will create a different .cfg file than when it's in Dinput mode.

  • @mitu As @stoney66 said, if you switch the mode, the controller is setup as if it is an entirely different controller.

    Logitech Gamepad F310.cfg is for the XInput Mode, while Logitech Logitech Dual Action is for DirectInput Mode.

    Anyway, I found something out through some tinkering. If the retroarch.cfg in /opt/retropie/configs/all is deleted, the controls work perfectly fine in all RetroArch Libretro emulators. Of course, I'm sure having done that I've introduced all manners of problems (such as the RGUI being changed to the XMB RetroArch menu style), but I have a backup I can use to reverse all my tinkering.

    So yeah, it would seem something in the retroarch.cfg in /opt/retropie/configs/all is causing issues.


    Here is another runcommand.log, but the verbose part seems to be broken after my tinkering.

    Executing: /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-fceumm/ --config /opt/retropie/configs/nes/retroarch.cfg "/home/pi/RetroPie/roms/nes/Super Mario Bros. (World).zip" --verbose --appendconfig /dev/shm/retroarch.cfg
    [INFO] RetroArch 1.7.3 (Git b2ceb50)
    [INFO] Redirecting save file to "/home/pi/RetroPie/roms/nes/Super Mario Bros. (World).srm".
    [INFO] Redirecting savestate to "/home/pi/RetroPie/roms/nes/Super Mario Bros. (World).state".
    [INFO] === Build =======================================
    Capabilities: NEON VFPv3 VFPv4 
    Built: May 14 2018
    [INFO] Version: 1.7.3
    [INFO] Git: b2ceb50
    [INFO] =================================================
    [INFO] Loading dynamic libretro core from: "/opt/retropie/libretrocores/lr-fceumm/"
    [INFO] [overrides] core-specific overrides found at /opt/retropie/configs/nes/FCEUmm/FCEUmm.cfg.
    [INFO] [overrides] no game-specific overrides found at /opt/retropie/configs/nes/FCEUmm/Super Mario Bros. (World).cfg.
    [INFO] Config: appending config "/opt/retropie/configs/nes/FCEUmm/FCEUmm.cfg"

    Also, here is what RetroArch did to my retroarch.cfg in /opt/retropie/configs/nes, which is currently working control-wise on my Logitech F310 (In XInput Mode).


  • Global Moderator

    @eckaji I think the NES system behavior is the result of deleting the main RA file. There's a retroarch.cfg.rp-dist that is the default one shipped with the package which can replace the one you removed.
    However, most of it is just comments and has only a few RetroPie additions - such as using RGUI as the menu driver and disabling the online update for cores.

    The only setting which might be related to the joypad is input_joypad_driver, which is by default udev. You can try re-adding back the file, then changing this to sdl2 and see if this fixes the mapping.

  • @mitu

    The only setting which might be related to the joypad is input_joypad_driver, which is by default udev. You can try re-adding back the file, then changing this to sdl2 and see if this fixes the mapping.

    Yeah, I tried that. Didn't change anything.

    I've decided to just restore my RetroPie install from a backup and avoid the Xpad driver update for the time being. I was able to update everything else individually without issue.

    Thank you for your time and I apologize for not seeing this through to end.

Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.