Swap Buttons A and B in RetroArch RGUI only

dankcushions

i think retroarch devs would probably suggest we move away from core overrides via -appendconfig and instead use their new built-in core override system. i think this issue shouldn't happen there, but i think it would be a big change for retropie.

meleu

@vbs said

Maybe rgui_show_start_screen = false should be added to the retroarch.cfg default config that Retropie is shipping (if this behavior of saving is intended by Retroarch)?

I think it would be a "workaround" too, but you can try to request it (if you want to make a PR, this is the file: retroarch.sh)

It would be better yet if you also open an issue on the RetroArch issue tracker detailing what happens and the steps to reproduce it. It would help if you mention that menu_driver.c part.

BuZz

@vbs said in Swap Buttons A and B in RetroArch RGUI only:

EDIT:
Maybe rgui_show_start_screen = false should be added to the retroarch.cfg default config that Retropie is shipping (if this behavior of saving is intended by Retroarch)?

The problem should be debugged first and taken up with retroarch if suspected it is a retroarch issue and not related to retropie configs.

BuZz

@vbs said in Swap Buttons A and B in RetroArch RGUI only:

Tested a bit: Retroarch saves the config on startup if the option rgui_show_start_screen is either true or not set. If it is not set (and the saving takes place) then it will be created with value false so Retroarch will not save the config on the following starts.

This is beyond my understanding currently. :(

Saving the config on exit is another story, but probably less mysterious since hopefully just triggered by save_config_on_exit.

Well, found the code that triggers config saving when start screen is enabled. Still does not make more sense to me (menu_driver.c:181):
if (settings->menu_show_start_screen)
{
   menu_dialog_push_pending(true, MENU_DIALOG_WELCOME);
   settings->menu_show_start_screen   = false;
   command_event(CMD_EVENT_MENU_SAVE_CURRENT_CONFIG, NULL);
}

I think the problem is the function used to only save config when save config on exit was on. So before it was a NOOP - now CMD_EVENT_MENU_SAVE_CURRENT_CONFIG will always save (a fix for another issue). This just needs some logic added I guess to only save the config if save config on exit is on.

BuZz

See https://github.com/libretro/RetroArch/issues/3605

vbs

@BuZz
Yes I did that already. The stuff I posted today was done on my regular Linux machine (no Retropie at all). I cloned Retroarch, compiled it and started it on the command line. Quite clean test setup IMO, no Retropie involved, used empty config file just with that single config option.

The question for me really is if that behavior is intended by Retroarch. If not, then they could fix it. If yes, then Retropie IMO needs a way to cope with it (maybe using that mentioned config option in the shipped retroarch.cfg).

EDIT:
Yes I read that issue. Sounds very similar but important parts seemed different (save on exit?), not sure if its the same. Most importantly: its not fixed :)

BuZz

I will submit a PR

BuZz

That issue introduced the problem - since the event would have not done anything before but now will.

vbs

@BuZz said in Swap Buttons A and B in RetroArch RGUI only:

That issue introduced the problem - since the event would have not done anything before but now will.

Hm not so sure, I also reproduced that issue on tag v1.3.6 (if I did not mess anything up) which is ~3 months old, but the issue you linked is just about 30 days old?

BuZz

I don't think 1.3.6 can have the issue, so please double check that.

vbs

@BuZz
I did that again on 1.3.6 and I am really quite sure that it suffers from the same issue.

Also the code looks very similar (at least that condition and the save command is in there also):
https://github.com/libretro/RetroArch/blob/v1.3.6/menu/menu_driver.c#L177

BuZz

The behaviour of command_event(CMD_EVENT_MENU_SAVE_CURRENT_CONFIG, NULL); changed - in 1.3.6 that will not save unless save config on exit is enabled. so make sure you don't have that enabled also.

BuZz

Unless there is something else at play, but I think the PR should resolve it anyway. try with https://github.com/libretro/RetroArch/pull/3787

vbs

I did some tests again. I really hope I didn't mess up cause I am doing like 3 things at once but this is what happens for me with the different versions:

'y' means "config gets overwritten upon startup"

v1.3.6 config_save_on_exit = true -> y
v1.3.6 config_save_on_exit = false -> n

master config_save_on_exit = true -> y
master config_save_on_exit = false -> y

your save_config branch = true -> y
your save_config branch = false -> n

Well, I really don't get it:

Why does the config get written upon startup at all?
Why is writing the config in any way related to "show start" screen?

BuZz

Because if the show start screen is enabled, and save on exit is enabled, it disables the screen, and saves config, so next time it won't show.

Someone made this decision at some point. The thing that broke was the function for saving config only saved the config if save on config was enabled. But this meant you couldn't manually save the config either from the GUI, so the restriction in the function was removed - however this caused this left over call to call it if the start screen is enabled.

vbs

@BuZz
Ahh ok thank you, understand.

Sorry for being annoying :) but another thought: when you install from binary on RPi you get version 1.3.6, right? When you install from source you get current master which basically is a surprise package. Why not also use 1.3.6 when installing from source so everyone gets the same, well defined, state?

BuZz

Because then people would complain they can't install the bleeding edge software.

I have some plans for improvements for this, but the x86 (source only) support is pretty new. Previously the idea was that you could get stable binaries, but also be able to install bleeding edge from source.

Most stuff doesn't break too much anyway, but RetroArch has been going through a lot of development.

vbs

@dankcushions said in Swap Buttons A and B in RetroArch RGUI only:

@vbs can be adjusted in RGUI or retroarch.cfg. eg:
# Menu buttons.
# menu_ok_btn          =
# menu_cancel_btn      =
you'll have to ucomment them first if they're commented like the above. i've never set them. guess it's set to the numeric js button. probably easier to do through the RGUI.

Sorry me again with this issue. I have this in my config for a while:

menu_ok_btn = "0"
menu_cancel_btn = "8"

and it worked well so far. I didn't touch Retroarch in a while but now it does not seem to work anymore. My A and B buttons are again "wrong". I also tried several other IDs instead of 0 and 8 but no difference at all.
Did something change there or any other ideas what the reason could be?

I also noticed that closing the menu using "Select + X" does not work anymore (which used to work in the past). I can open the menu with it but I cannot use it to close it again. I always have to choose "Resume" from the quick menu.

EDIT:
Sorry I think I did not mention the environment: I am using latest Retropie on an Intel i5 NUC on Lubuntu 16.04 with Xbox 360 Wireless controllers.

BuZz

@vbs the hotkey to exit retroarch is a known issue - there is an upstream ticket and at least 2 topics on it - https://retropie.org.uk/forum/topic/5161/unable-to-exit-retroarch-menu / https://github.com/libretro/RetroArch/issues/3899#issuecomment-259129721

The other issue should be reported to retroarch.

vbs

@BuZz
Ok, thanks I reported that issue with the menu button mapping.
https://github.com/libretro/RetroArch/issues/4111

I really feel a bit unsure if the error is maybe just on my side. Can someone confirm that it is a general bug in current RetroArch?