RetroPie forum home
    • Recent
    • Tags
    • Popular
    • Home
    • Docs
    • Register
    • Login
    Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

    Creating a custom SDL2 gamepad mapping?

    Scheduled Pinned Locked Moved Help and Support
    sdl2customgamepadmap
    8 Posts 2 Posters 3.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      sleve_mcdichael
      last edited by

      My generic Amazon SNES pad doesn't always work right in non-libretro apps. It has been suggested I might fix this by "setting an environment variable with a custom map created using an SDL2 gamepad mapping tool" (specifically, they suggested the second one listed below).

      I have found a couple such tools at https://github.com/gabomdq/SDL_GameControllerDB#mapping-tools, but I'm not quite sure how to use them.

      The first one (partially deprecated), from General Arcade, has Linux downloads available for "i386" and "amd64" -- these both mean "not Raspberry Pi, which is ARM, which is different," right? There's also a Windows version but I have limited access to PC. Is that what I need to use?

      The second one has an "x86_64.appimage" download which I'm sure is not RPi, and also has source code but no instructions. make didn't work and I don't know what else to try without some hand-holding.

      The third option says use the controllermap utility distributed with SDL2 and links to here. I downloaded and compiled that (best I knew how, with mkdir build && cd build && cmake -DCMAKE_BUILD_TYPE=Release .. && make) but it just made an executable .so file that gave a runtime error when I tried to run it, with or without the --help flag.

      The fourth option is Steam. I don't have Steam.

      Can I compile and run the second tool on my RPi4, or will I need to use the Windows version of the first one, when I can get some time on the PC? Or is there another option?

      mituM 1 Reply Last reply Reply Quote 0
      • mituM
        mitu Global Moderator @sleve_mcdichael
        last edited by mitu

        @sleve_mcdichael said in Creating a custom SDL2 gamepad mapping?:

        The second one has an "x86_64.appimage" download which I'm sure is not RPi, and also has source code but no instructions. make didn't work and I don't know what else to try without some hand-holding.

        Looks like a QT application. Run qmake first then make (you need to have installed the QT dev tools first, installing skyscraper should do that). You'll need to run it from the desktop, since it's a graphical app.

        The third option says use the controllermap utility distributed with SDL2 and links to here. I downloaded and compiled that (best I knew how, with mkdir build && cd build && cmake -DCMAKE_BUILD_TYPE=Release .. && make) but it just made an executable .so file that gave a runtime error when I tried to run it, with or without the --help flag.

        The utility is in the test sub-folder, run (from that folder) ./configure && make controllermap.
        It will fail miserably, since the libSDL2 used by RetroPie is older than the latest release. So, clone the retropie-2.0.10 branch from https://github.com/retropie/sdl, which will give you the same SDL version as on RetroPie. Repeat the same steps above (you don't need to compile the library, just use the test folder) and you should get a 'controllermap' program.

        S 1 Reply Last reply Reply Quote 0
        • S
          sleve_mcdichael @mitu
          last edited by sleve_mcdichael

          @mitu said in Creating a custom SDL2 gamepad mapping?:

          So, clone the retropie-2.0.10 branch from https://github.com/retropie/sdl, which will give you the same SDL version as on RetroPie. Repeat the same steps above (you don't need to compile the library, just use the test folder) and you should get a 'controllermap' program.

          Great, that gave me something that looks like what I need. So now I need to make this an environment variable. Am I right to do that by adding:

          SDL_GAMECONTROLLERCONFIG="<string>"
          

          ...to /etc/profile (anywhere outside an if statement?)

          Do I then need:

          export SDL_GAMECONTROLLERCONFIG
          

          ...after that?

          EDIT: and there is already an entry in the database, with the same ID but different button values. This will override that default?

          mituM 1 Reply Last reply Reply Quote 0
          • mituM
            mitu Global Moderator @sleve_mcdichael
            last edited by

            @sleve_mcdichael said in Creating a custom SDL2 gamepad mapping?:

            Do I then need:
            export SDL_GAMECONTROLLERCONFIG

            ...after that?

            Yes, but you can shorten it to:

            export SDL_GAMECONTROLLERCONFIG="string"
            

            Also, don't use the global profile, either add it to autostart.sh or to $HOME/.profile.

            EDIT: and there is already an entry in the database, with the same ID but different button values. This will override that default?

            Probably yes, but I'm not entirely familiar with this SDL hint.

            S 1 Reply Last reply Reply Quote 0
            • S
              sleve_mcdichael @mitu
              last edited by

              @mitu said in Creating a custom SDL2 gamepad mapping?:

              Probably yes, but I'm not entirely familiar with this SDL hint.

              I added the line to $HOME/.profile and relogged. This works, thanks!

              1 Reply Last reply Reply Quote 0
              • S
                sleve_mcdichael
                last edited by sleve_mcdichael

                @sleve_mcdichael said in Creating a custom SDL2 gamepad mapping?:

                I added the line to $HOME/.profile and relogged. This works, thanks!

                Well....this worked when I tried launching them from terminal. Still got nothing when launching from ES. Moving it to autostart.sh seems to have done the trick, though. .profile must not be processed until after autostart.sh completes, or something?

                Edit: and now it doesn't work from terminal. It works by both methods, only if I have the line in both places. Is there a way to make this work by only setting it in one place somewhere? Why shouldn't I put it in the global /etc/profile? Would that even work or also not until after ES exits from autostart, like the user profile seems to.

                1 Reply Last reply Reply Quote 0
                • mituM
                  mitu Global Moderator
                  last edited by

                  Try maybe adding the export command to $HOME/.bashrc.

                  S 1 Reply Last reply Reply Quote 0
                  • S
                    sleve_mcdichael @mitu
                    last edited by

                    @mitu said in Creating a custom SDL2 gamepad mapping?:

                    Try maybe adding the export command to $HOME/.bashrc.

                    That also worked from terminal but not from ES.

                    So what I think is happening is this: autostart.sh is called from /etc/profile.d/10-retropie.sh which runs as part of /etc/profile. Then once that's complete it calls .profile and .bashrc.

                    But since the environment var is set in autostart it is perhaps disconnected from the profile service and so maybe the variable is local only to that shell. So it works from inside ES but when I exit ES and the autostart shell terminates, the var goes away and it doesn't work from terminal.

                    When I set it in .profile or in .bashrc it works from terminal, but these aren't processed until after ES exits because that's part of autostart which happens while /etc/profile is still going on.

                    1 Reply Last reply Reply Quote 1
                    • First post
                      Last post

                    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.