Dolphin (GC) - Automated controller mapping and hotkey script

[retropieuser]

I've created a rough script so far that does the following:-

• Scans for js profile controllers and gets the evdev device name
• Creates a profile ini for that controller
• Updates the Hotkey.ini file with that controller for that play session
• Checks the Rom's gameID then uses it to create a game specific .ini file, which you then use to pull the controller profile from (as Dolphin cannot pull profiles directly from the global dolphin.ini)

Please can you check and test this, as I only own 8bitdo controllers but I've managed to get them all mapping as well as expected making guesses. Roughly as successful as the mapping process is for mupen64plus

Let me know of some changes, I'm happy to tidy this up as it's quite messy right now

[GoldenPalazzo]

I found some issues: firstly, if some gamepads have the same evdev name, hardcoding "evdev/0/{controller_name}" maps the GameCube virtual gamepad to the same real gamepad; also, the idea is nice but probably not replicable for Wiimotes...? I know it's only for GameCube, but would be also nice to handle Wiimote profiles since the emulator is the same.

EDIT:
To solve the evdev issue, an approach I thought about is to create a new GCPad.ini file and paste the profiles directly to dynamically address the gamepad naming issue with the correct index.

Moreover another issue I got is that the Hat naming convention is SDL exclusive and all the d-pads on my gamepads (offical DS4, official Xbox One controller, Anbernic RG P01, Logitech F710) all report axes instead of hats while using the evdev handler on Dolphin, while using the SDL input handler I can use them with success (with a few tweaks since Dolphin seems to not like "Hat 0 Up" but "Hat 0 N" and so on...). If all your 8bitdo gamepads worked, probably it's because they actually use hats for the dpad on the evdev handler (assuming, haven't still tried).
The new problem is that by using the SDL handler the namings you get at the start of the script is completely wrong (example: my Dualshock 4 exposes to evdev as "Sony Entertainment Wireless Controller" and to SDL as "PS4 Controller"), so now basically the launching script should also be able to get the SDL naming.

[retropieuser]

I found some issues: firstly, if some gamepads have the same evdev name, hardcoding "evdev/0/{controller_name}" maps the GameCube virtual gamepad to the same real gamepad; also, the idea is nice but probably not replicable for Wiimotes...?

EDIT: To solve the evdev issue, an approach I thought about is to create a new GCPad.ini file and paste the profiles directly to dynamically address the gamepad naming issue with the correct index.

Can you show me the example with the correct indexes? I agree if you had 2 of the same evdev name it probably would fail and it'd be nice to have a solution to that scenario

Also I noticed myself as I did a fresh install, the hotkey.ini file and /Profiles/GCpad.ini isn't necessarily created when installing Dolphin or when booting for the first time, so I'll add some checks for the directories and files existence

Moreover another issue I got is that the Hat naming convention is SDL exclusive and all the d-pads on my gamepads (offical DS4, official Xbox One controller, Anbernic RG P01, Logitech F710) all report axes instead of hats while using the evdev handler on Dolphin, while using the SDL input handler I can use them with success (with a few tweaks since Dolphin seems to not like "Hat 0 Up" but "Hat 0 N" and so on...). If all your 8bitdo gamepads worked, probably it's because they actually use hats for the dpad on the evdev handler (assuming, haven't still tried).
The new problem is that by using the SDL handler the namings you get at the start of the script is completely wrong (example: my Dualshock 4 exposes to evdev as "Sony Entertainment Wireless Controller" and to SDL as "PS4 Controller"), so now basically the launching script should also be able to get the SDL naming.

I agree the HAT/Analog problem would need a solution as well, not sure how we can know how dolphin will treat the controller, I'm about stuck there as 8bitdo seem to follow their own rules and always use HAT but I'm sure other manufacturers use different things.

And lastly, that naming controller for SSL is the reason I'm using evdev as no idea why Emulationstation and Dolphin appear to name SDL devices different names and it doesn't appear to be universal across applications?

[GoldenPalazzo]

Can you show me the example with the correct indexes? I agree if you had 2 of the same evdev name it probably would fail and it'd be nice to have a solution to that scenario

By creating a fake device with the same name I got

SDL/0/PS4 Controller
SDL/1/PS4 Controller

Basically puts an index based on who connected first.

I agree the HAT/Analog problem would need a solution as well, not sure how we can know how dolphin will treat the controller, I'm about stuck there as 8bitdo seem to follow their own rules and always use HAT but I'm sure other manufacturers use different things.

Your script is basically perfect to be used with SDL namings instead execpt for the directions of the hats: simply replace the directions up/down/left/right with the cardinal directions n/s/w/e and it works flawlessly.

And lastly, that naming controller for SSL is the reason I'm using evdev as no idea why Emulationstation and Dolphin appear to name SDL devices different names and it doesn't appear to be universal across applications?

evdev naming is consistent because it's something external to SDL, it's just a kernel interface; SDL directly pulls names from their gamecontrollerdb.txt if I'm not mistaken.
I too would prefer using evdev instead of SDL2, but since input namings are not consistent, it's probably preferable switching to SDL for the sake of consistency.
A way I found to workaround this is by taking account of both SDL gamepad name and evdev gamepad name, the first to dynamically adjust the controller index for Dolphin in case of namesakes, the second to find the autogenerated config by your script.
I also have tried rewriting from scratch the Dolphin launcher to apply what I said earlier and it seems to be working nicely, also by expanding your script to support Wii gamepads.

[retropieuser]

forgive my ignorance on GitHub, are you able to add your own commit or suggested changes please?

I'd find it easier taking a look at the code lines than the description if that makes sense

I agree about the wiimote support for most users. I use a dolphin bar and old wiimotes as I find that gives me the easier experience, but that is a niche setup I have

[mrobss]

How do you go about installing this? I'd like to give it a try on my build of Dolphin.

[GoldenPalazzo]

forgive my ignorance on GitHub, are you able to add your own commit or suggested changes please?

I'd find it easier taking a look at the code lines than the description if that makes sense

Yes, as soon as I have a bit more time after my exams I'll try to incorporate my edits with your branch.

I agree about the wiimote support for most users. I use a dolphin bar and old wiimotes as I find that gives me the easier experience, but that is a niche setup I have

Not as niche as you think, unfortunately my dolphin bar broke so I'm not able anymore to try to support real wiimotes.

[GoldenPalazzo]

How do you go about installing this? I'd like to give it a try on my build of Dolphin.

At the moment you could try putting the configscripts/dolphin.sh in /opt/retropie/supplementary/emulationstation/scripts/configscripts/ and at the moment I'm not really sure about what's the best way to test the dolphin loader

[retropieuser]

forgive my ignorance on GitHub, are you able to add your own commit or suggested changes please?
I'd find it easier taking a look at the code lines than the description if that makes sense

Yes, as soon as I have a bit more time after my exams I'll try to incorporate my edits with your branch.

I agree about the wiimote support for most users. I use a dolphin bar and old wiimotes as I find that gives me the easier experience, but that is a niche setup I have

Not as niche as you think, unfortunately my dolphin bar broke so I'm not able anymore to try to support real wiimotes.

Good luck with your exams 👍👍

Dolphin bar is 100% the way to go. So many Wii and wiiware games are built with the control scheme in mind. It's just not the same playing Mario & Sonic Olympics without the waggle control

[mrobss]

So I've been messing around with the automapping and controller detecting script, I've now been able to get it to work pretty successfully, and I've tested it with a number of different controllers and it is working fine, except for one..... the 8Bitdo Pro 2 controller.

I think this is the issue. When emulationstation detects the controller it sees it as this:

but it saves it as a file called:
8BitDo Ultimate Wireless Pro 2 Wired Controller.ini

and in that file the ID is this:

[Profile]
Device = evdev/0/8BitDo Ultimate Wireless / Pro 2 Wired Controller

And it doesn't load or work. In fact, it gets confused and loads the profile for whatever the last controller I had.

I think it doesn't like the slash "/" in the ID as it may be looking for it in the file name but the file name cannot have that character in it.

I have noticed that the dolphin script needs to have the exact file name match the controller device ID for it to work.

Do you have any idea what database file emulationstation is pulling those Device ID's from and maybe I can try changing the name from "8BitDo Ultimate Wireless / Pro 2 Wired Controller" to "8BitDo Ultimate Wireless Pro 2 Wired Controller" and I have a feeling that will work.

Anyone have any thoughts?

[mrobss]

So a little update. I can confirm that the script works just fine with at least ten different controllers I just tried. The only trouble I'm having is with the above 8Bitdo controller that puts the "/' slash in the device name.

Any ideas on how to remove that or work around that?

Here's all the devices I have tried so far:

[mrobss]

Instead of re-posting here, I have posted all my findings and work arounds for this issue on the RetroPie support forum: https://retropie.org.uk/forum/post/301779

[GoldenPalazzo]

So I've been messing around with the automapping and controller detecting script, I've now been able to get it to work pretty successfully, and I've tested it with a number of different controllers and it is working fine, except for one..... the 8Bitdo Pro 2 controller.

I think this is the issue. When emulationstation detects the controller it sees it as this:

but it saves it as a file called: 8BitDo Ultimate Wireless Pro 2 Wired Controller.ini

and in that file the ID is this:

[Profile] Device = evdev/0/8BitDo Ultimate Wireless / Pro 2 Wired Controller

And it doesn't load or work. In fact, it gets confused and loads the profile for whatever the last controller I had.

I think it doesn't like the slash "/" in the ID as it may be looking for it in the file name but the file name cannot have that character in it.

I have noticed that the dolphin script needs to have the exact file name match the controller device ID for it to work.

Do you have any idea what database file emulationstation is pulling those Device ID's from and maybe I can try changing the name from "8BitDo Ultimate Wireless / Pro 2 Wired Controller" to "8BitDo Ultimate Wireless Pro 2 Wired Controller" and I have a feeling that will work.

Anyone have any thoughts?

Errata corrige: EmulationStation actually uses SDL without HIDAPI, this means that displayed names may or may not coincide with evdev names.

Both EmulationStation and Dolphin take the evdev name exposed by the device. There is no way to change it.

Sanitize filename snippet is directly taken from the retroarch autoconfiguration script, so the issue lies more in the selection of the profile when launching the game.
The autoconfiguration basically removes every irregular character when naming a file, but doesn't seem to be the case when finding the corresponding config when loading the emulator. It just removes trailing and leading whitespaces.

[mrobss]

So is there no way to fix it? Because the file name needs the irregular slash character but the file name cannot have that character?

[GoldenPalazzo]

Actually the solution is quite simple, since you just need to run the sanitise filename snippet when selecting the profile.
But how can we get the exact name of the gamepad?
@retropieuser's solution was to manually parse /proc/bus/input/devices, but these are evdev names, and as we noticed before EmulationStation actually uses SDL joystick names with SDL_JOYSTICK_HIDAPI=0, which adds another layer of complexity because Dolphin instead uses SDL gamepad name.
The difference lies between the different functions used to get names.

So we need to get both names: we need joystick name to get the config file written by ES, and the gamepad name to write the Device = SDL/i/gamepadname line in the config.

At this point, the old approach of putting a PadProfile becomes useless because we need to dynamically adjust the device name, since we are getting it from the sdl functions when loading the game, and also because if there are two or more devices with the same name, all dolphin gamecube gamepads will point to the same gamepad: the one with the index 0.

In my opinion, the entire loading script needs to be rewritten, while the autoconfig one adapted to SDL mapping conventions and add support for Wiimotes.

[mrobss]

Well, that seems like a lot of work? I've already gotten about 30 different controllers to work with this script and having ONE that doesn't work, where I did actually find a work-around for (pairing it via bluetooth with the Pi directly) so maybe just leave it as is?

[mrobss]

.m3u files do not work. The game loads up but it does not detect or change the controller profile.

[mrobss]

Here is another issue I've found...

When you have two controllers connected only the 2nd controller has the hotkey. If you try to exit a game with the first controller it won't work.

This isn't a huge issue as you can exit with the second controller but if you try to connect a controller like the PS5 controller, it creates a "2nd profile" for the motion controls and assigns player 2 to that. So if you connect a PS5, you cannot exit a game with the controller because the hotkey is on a controller that don't actually exist.

[mrobss]

I think I just found a pretty significant bug… if you connect four controllers that emulationstation identifies as the same, for example “four XBOX 360 controllers” then all four controllers are controlled by the first controller.

If you connect controllers that identify as different, like an XBOX 360, PS3 controller, 8bitdo, and so on…

But two or more controllers of the same ID will all be controlled by the first one.

Test it on Mario Party 4 and when you try to select a character, the first controller controls all four characters and the other three are dead.

[mrobss]

Can you show me the example with the correct indexes? I agree if you had 2 of the same evdev name it probably would fail and it'd be nice to have a solution to that scenario

By creating a fake device with the same name I got

SDL/0/PS4 Controller SDL/1/PS4 Controller

I see you were reporting the same bug I was. What did you mean "by creating a fake device?" Were you able to find a work around for this to get multiple versions of the same controller type working?

[GoldenPalazzo]

Can you show me the example with the correct indexes? I agree if you had 2 of the same evdev name it probably would fail and it'd be nice to have a solution to that scenario

By creating a fake device with the same name I got
SDL/0/PS4 Controller SDL/1/PS4 Controller

I see you were reporting the same bug I was. What did you mean "by creating a fake device?" Were you able to find a work around for this to get multiple versions of the same controller type working?

I ran a script that exposed a fake device with a custom name, since I do not own duplicate gamepads and had no way to test it