L button is sent on "Emulator Quit" action via radial

[XargonWan]

When you quit retroarch with the radial, on first click it will change the color layout of monochrome games (I.e. game boy). Maybe a double hotkey is triggered?

[XargonWan]

Moreover on RetroArch it asks you the quit confirmation and on the radial is not a good UX choice.

Possible fixes:

• We disable the confirmation from RetroArch and it will qui directly even nto the radial call
• We add to the radial the double hotkey sending for retroarch, so the quit button will be sent twice only on radial

[XargonWan]

I found the issue:

• Previous color palette is Q (so CTRL+Q)
• Previous color palette is E (so CTRL+E)

We should clear these hotkeys.

[XargonWan]

Not really sure how to fix this since If I rebind that buttons I'm actually rebinding L and R.

Moroever that menu entries are strange to me, here is a comparsion with my computer (Ubuntu). left: Steam Deck, right: my computer (Ubuntu), same RetroArch and Gambatte versions. The name of the buttons are completely different

Italian translations: L Button (side) R Button (side)

[XargonWan]

It's not a GB gambatte issue, it's an issue of how we manage the CUP. Basically we are calling CTRL+Q and ALT+Q when quitting an emulator with the radial, but Q and W are L and R in RetroArch, and for some reason it's not sending the CTRL+Q combination only, but it's even sending the Q button alone. So each time we quit an emulator we are basically pressing L button in the game. Because natively the Game Boy don't have L and R buttons, in the libretro core gambatte they were assigned as the palette swap. But I believe the same is happen with every emulator, so when we're quitting SNES, for example, L is sent as well.

A possible fix could be to instruct the steam controller profile that when I press the quit radial button It's not sending:

• CTRL + Q
• ALT + Q
• Q

But only:

• CTRL + Q
• ALT + Q

[XargonWan]

I realized that our steam input is actually sending both of the buttons separately: https://github.com/XargonWan/RetroDECK/blob/9e12d859a33db92f21830fc5a365c4b42fa387d8/emu-configs/defaults/retrodeck/RetroDECK_controller_config.vdf#L3154-L3164

This might be interesting to solve the case as we would send a button chord and not the single keys: https://www.reddit.com/r/SteamDeck/comments/xyh2c7/is_there_any_way_to_set_up_a_combination_of/

[XargonWan]

Update: button chord is not working, it seems like a Steam Input bug, we should report to them and link the issue here.

[reyemxela]

I ran into this problem recently, saw in the docs that it was a known issue, and found this thread.

While it's mostly Steam Input's fault (there needs to be a better/more reliable way to send key combos), there does seem to be a way around it.

Instead of adding Q as a sub-command to Control, add it as an "extra command". This allows custom start/end delays for each keypress. For some reason, the timings needed to be pretty long for Retroarch to behave nicely, but it works.

Relevant snippet for this method:

"touch_menu_button_1"
{
	"activators"
	{
		"Full_Press"
		{
			"bindings"
			{
				"binding"		"key_press LEFT_CONTROL, Exit / Quit Emulator, RD-process-stop.png, "
			}
			"settings"
			{
				"delay_end"		"200"
			}
		}
		"Full_Press"
		{
			"bindings"
			{
				"binding"		"key_press Q, , "
			}
			"settings"
			{
				"delay_start"		"100"
			}
		}
	}
	"disabled_activators"
	{
	}
}

I whipped up a quick input event logger in Godot to help me visualize what all is happening. Using the current sub-command method, my test app sees:

1. Control press
2. Q press
3. Control release
4. Q release

By adding even tiny delays (end delay to Cotnrol, start delay to Q), my app saw the expected order of:

1. Control press
2. Q press
3. Q release
4. Control release

but as mentioned above, Retroarch seems to need much higher delay values.

[Lazorne]

Thanks for you investigation!

I will look into it more and with our complexity that it have to work for all the applications we ship.

There needs to be a better/more reliable way to send key combos.

I really agree!

But it is not only about key combos but also about:

• Radial menus
• Unifying the inputs via a virtual controller
• Player controller order
• Much more.

The sad reality is nothing better exists as of now for Linux.

The most interesting FOSS project is OpenGamePadUI and we are keeping our eyes on it, but they are not there yet in term of features.

Steam Input is the best alternative we have currently.

We got some FOSS input developers in the RetroDECK community but they mostly talks about handling raw input data and making sure X is X and Y is Y.

But what we are doing with Steam Input is beyond X is X and Y is Y.

I wish there was a more global discussion in the FOSS community about game inputs and the kind of features Steam Input provide.

Player controller order is such a thing I think should not be handled by one application, but some kind of global variable within the OS itself or some other way that all applications could call to get the current input order.

The consoles can do it, so why could the Desktop OSes not also get that feature.

These are just my thoughts :)

[reyemxela]

Oh, sorry, when I said there needs to be a better way to send key combos, I wasn't talking about an alternative to Steam Input. I think Steam Input is awesome, and this project is using those features you mentioned (radial menus, etc) very nicely.

I just meant Steam Input itself needs a better way to send key combos (such as ctrl+q). Right now, you either do it the current way with sub-commands which seems to just send both keys "at once" causing timing issues, or you have to do the method I mentioned with somewhat arbitrary delays.

But obviously that's not anything we can change, so something like the extra command + delays is needed for now.