Swap Buttons A and B in RetroArch RGUI only

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?

meleu

@vbs I noticed it (A and B reversed) on my Android (using a RetroArch buit on 2016-11-27). I'll update from source on RetroPie and check it.

UPDATE: I've just noticed that someone answered your issue with some news: https://github.com/libretro/RetroArch/issues/4111#issuecomment-264021380

meleu

@vbs I think you're going to see this on your issue, but let me put it here for future reference:

The menu_ok_ btn and menu_cancel_btn are now deprecated on RetroArch. The Retropad B button is "Cancel" and the Retropad A button is the "OK". The only option you have is to swap them setting menu_swap_ok_cancel_buttons = "true".

edit: corrected the option name.

vbs

@meleu
Thanks alot mate!
But I think the option is named menu_swap_ok_cancel_buttons(rather than menu_swap_ok_cancel). Just if someone else stumbles upon this...

meleu

@vbs you're right. And it was already fixed. :-)
Cheers!