RGui Control Conflict
-
There's an issue with the RetroPie version of RetroArch that arises when the 'Enter' key is mapped to the 'A' button of player one. All goes well in a game, but when you invoke the RGui, pressing 'A' produces a double tap of 'Enter'. This makes it impossible to navigate menus, as you're always going two menus deep. This behavior is not found in the Windows or Mac version of RetroArch.
I have created a gamepad control scheme that can control every emulator in RetroPie, including all those normally bound to a mouse and keyboard, but this quirk seems to be the final road block. Does anyone have an idea what this issue stems from?
-
Just a thought that might point you in the right direction...
In Retroarch settings, under input, note that each input has a button and a key assigned to it. If you setup the keyboard in EmulationStation to have Enter = A, and then also in RetroArch you have both A and Enter assigned to the same input, perhaps it is registering that you pressed both A and Enter. This could possibly be triggering the double tap because it thinks your pressing A and Enter at the same time.
I may not have described exactly what the scenario is, but I suspect something like this is happening...
-
It's a very good thought and one that I've been entertaining myself, but I've never been able to make the connection fully. I mean, Emulation Station is scripted to alter input settings once after the mapping procedure. I've checked the RetroArch config file and can't find a second entry that might conflict. Whatever the case may be, I think it is indeed getting input from two separate device settings.
-
It appears as though the same thing happens when the 'Delete' key is mapped to the 'B' button. Only this time you'll move backwards two levels through the menu system. Could these keys be hardcoded into the software specifically in the RetroPie version of RetroArch for some reason?
-
Nothing like that hardcoded specially in the RetroPie version.
It could well be a RetroArch issue, but you should check the
configs/all/retroarch.cfg
where the keyboard mappings are stored. -
Thanks for chiming in @BuZz. I was hoping to hear from a project team member on this. I've been working on this universal control scheme for nearly three months and to be so close to finishing, only to run into a bizarre issue like this is terribly frustrating. However, I'll do what I always do and put it aside for a while and hope the answer comes to me in time. Thanks again to both of you.
-
I was curious about the issue, so when I got home I booted up my RPi with only my keyboard plugged in.
I have the letter A mapped to the A button, which works to select menu items, but Enter also works. Enter is mapped to the Start input, but Start on my controller does not work to select menu items. Only the A button does.
Seems to indicate that Enter is hardmapped to A when in the menu and would explain your double input problem.
-
Oh and for me, Backspace will move back one level even though I have the letter B mapped to B (which also works to move back one level).
Now you just need to figure out where the hardmapping comes from.
Fyi, my previous post about having a gamepad button and key assigned to the same input doesnt seem to apply here. For example, my setup when my ps3 controller is plugged in says A is mapped to button 14 and key a. Says nothing about enter. So I can use the X button on my ps3 contoller, the letter a, and enter to select menu items while in the menu...
-
The mapping is probably hardcoded in RetroArch (possibly https://github.com/libretro/RetroArch/blob/7d93f63e6a1c39eeefd9ec00400b27be07c14dbf/menu/menu_driver.c#L211 - I just did a quick search of the sourcecode, so it might be wrong) - you can open a ticket here for clarification - https://github.com/libretro/RetroArch/issues
-
To solve the issue temporarily, you could swap a and x (example) in the user binds, and then use control remaps for the cores to swap them back (in game quick menu > control). This way, Enter would be X in the menu (plus the hardcoded menu select input), but in the game it's remapped to whatever A is supposed to be. Make sense?
-
I really appreciate the extras eyes on this to confirm what I was seeing. I can't reproduce the problem on Windows or the MacOS, so maybe it's a Linux-specific issue. I'll open a ticket and see what the RetroArch team has to say. Thanks BuZz, for searching the sourcecode. I need to learn how to do that somewhere down the road. Also, thank you Concat for the map testing. I was beginning to think I was imagining the whole thing ;).
In an effort to move forward with my own goal, I'll have to rethink and even compromise the idea of a universal gamepad control scheme for now, but I have a few ideas in mind to easily allow switching between control schemes for all the systems that currently lack Joystick support. Perhaps a series of script templates that can easily be installed and launched from a sub-directory in the 'RetroPie' menu in Emulation Station. This might be better in the long run as the end user could duplicate and configure the templates on a game-by-game basis for systems like the ColecoVision that need a more refined control scheme depending on the game.
Edit: Also, thanks for the last suggestion Concat. While it doesn't meet the global requirements I need, I'm definitely going to keep that trick in mind for the future.
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.