Swap Buttons A and B in RetroArch RGUI only

meleu

@dankcushions he is using the x86 RetroPie, it means he installed RetroArch from source.

@vbs the comments I've found in the retroarch.cfg skelleton

# Show startup screen in menu.
# Is automatically set to false when seen for the first time.
# This is only updated in config if config_save_on_exit is set to true, however.
# rgui_show_start_screen = true

vbs

@dankcushions
I just tested that on commit a800ab68eefef700053d20b282cdf20b093d34d9 which is the latest commit on master branch.

I really don't see the point why showing the start screen should be related to dumping the config in any way :(

EDIT:
Hm, also happens on tag v1.3.6

meleu

@vbs was your problem solved? (that non-expected dumping into the system retroarch.cfg file)

vbs

@meleu
Well, "solved" is a big word :) I think I could workaround it by resetting all retroarch configs and inserting rgui_show_start_screen = falsein the global retroarch.cfg before starting any core for the first time (which would be ok for me now). But I am usually also interested to make Retropie more stable in the long term. So I think it would still be great if someone more knowledgeable could join in with an explanation (is it a bug? is it a feature?) or a good idea.

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)?

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?