NVidia Shield 2019 Remote: Swap buttons used as A and B #839
Conversation
The existing config used the back button on this remote as "A" and the center button as "B". In the default UI, this meant that you need to hit the back button to select an option and the center button to back out. This seemed backwards, so I swapped them.
My guess is that whoever uploaded this configuration was using Nintendo-style controls in their RetroArch UI. Since that wasn't the default in my setup, I don't think it should be the default here. I understand this is a weird case where the remote doesn't resemble a real controller, though, and maybe I'm wrong if the RetroArch default orientation ("Menu Swap OK and Cancel Buttons") changes in cases I'm not aware of.
I could probably go on about a deeper code change that might be a more correct fix that works in all cases, but I don't know that there's interest or that it'd be worth it, so I just proposed this.
|
hmm, that's a tough call. While you're obviously correct that the current result is unintuitive, the A/B swap is only there for the Shield controller and it seems weird to change the remote mapping to work around something we're already changing... IMO, we would just not swap A/B by default and let users set it, but that would certainly upset a lot of people, too. No perfect answer, I guess. |
|
Huh, my email reply didn't get though. Trying on the website... and thanks for entertaining the topic, it's definitely niche of niche :). I'm a bit confused by what you're saying. So I'll be very explicit what I think is the case, so you can tell me where I'm wrong. Not trying to be argumentative, even though it might come across that way :).
On Android at least (similar to Windows, Xbox, Linux, Mac, and most things besides Nintendo, even in Japan nowadays), Xbox style is the standard. RetroArch seemed to follow that standard for me, with a Shield controller, Xbox-compatible controller, etc., it works as expected. A/bottom button confirms, B/right button backs out. Yes, the option in RetroArch is called "Menu Swap OK and Cancel buttons" and in my setup it's "ON" by default, but that seems like semantics. "ON" being the default means means Xbox layout is "standard" (which makes sense on Android too). With the Shield remote, given the above, to at least be functional in the UI, it'd make sense IMO for the back button to actually mean back and the selector button to actually select something. It seems less likely for someone to actually play a game with this remote, but if they wanted to play a Nintendo game, it'd make sense IMO to then remap it for that console or game, though I'm not even convinced they'd want to much of the time, and it'd have to be a per-game thing anyway, because gaming on this remote would be weird. One reason I could be wrong is if there is some intent for Nintendo or old-Sony-in-Japan style to actually be the primary orientation in the UI even if that's not the case right now. Even as someone who owns more Nintendo consoles than anything, I'd be surprised at this. Am I confused about anything above? |
|
The default behavior is indeed Nintendo/Sony-in-Japan -style. We detect Shield hardware and apply some settings on a hardcoded basis (I think mainly as a result of the old Shield portables being extremely weird and difficult to configure without special-casing), one of which is the 'swap ok/cancel buttons'. So, the current behavior is to take the properly-mapped remote and automatically make it weird to benefit other input devices. We could, as you've submitted, make the autoconfig incorrect to compensate for our own automatic-weirdness (which is, itself, trying to accommodate other input devices), and this would be a simple and effective solution for making remotes work as expected. However, it's also a band-aid on top of a band-aid on top of a band-aid, which is not usually a great place to be, long-term. The alternatives would be to 1) no longer automatically apply the ok/cancel swap, which makes the remote work properly and makes the shield controller work the same as any other pad on any other platform at the expense of being contrary to the way the Shield menus work, or 2) leave everything as-is, where remotes are wonky. I wouldn't worry much about making the remote mapping incorrect, except that I think some other projects use our autoconfig profiles, and that would leave them with a bad mapping. My personal preference would be alternative 1 as listed above, but I'm not actually against this one, either. I just wanted to make sure we look at all of the angles :) |
|
I see, interesting!
The default button mapping will get more and more relevant on various
platforms. There are more Android devices shipping with built-in
controllers, e.g. AYN Odin, and of course the Windows and Linux portable
gaming devices like the Steam Deck and Aya Neo devices. And many of them
let you dock to a TV and use external controllers. And Android/Google TV
itself seems to be growing.
My guess is that, ignoring the existing user base for the moment, making
the Shield devices a weird special case doesn't make sense in the long run,
because these other platforms have the same issue of whether to make
RetroArch match the system UI. Personally, I suspect Xbox style is the
right choice on Android, Linux, and Windows as a default, but I don't see
the user behavior like an actual RetroArch dev does. But every other thing
I use on the Shield (including emulators) expects A as select and B as
back, probably because of the guidelines Google publishes Android-wide:
https://developer.android.com/training/tv/start/controllers . (There might
be a better source; I'm not an Android dev.)
Of course, install base and dev effort are concerns, so yeah, I don't know
:).
On remote controls, head in the clouds mode, I'd probably have the
controller configs optionally let you specify OK/back buttons instead of
A/B/etc. and have that mapped in RetroArch depending on swap state. Is it
worth the effort? I don't know. I get the impression the RetroPad
abstraction is embedded pretty deeply.
Without that big input mapping change, back to this particular pull
request, knowing the background, I don't have strong feelings about it.
This can't be a common issue and can wait on if/when y'all deal with the
questions above. I will use the OK/Cancel swap and this changed remote
control setting personally though.
|
|
Sounds good. Let's leave this one open for a while, then, and see if anyone else chimes in. |
|
Thanks for entertaining the topic, it's definitely niche of niche :).
I'm a bit confused by what you're saying, so I'm going to try to be very
explicit in case there's some confusion. So I'm just trying to be clear
what I *think* is the case, so you can tell me where I'm wrong. Not trying
to be argumentative, even though it might come across that way :).
- This isn't the Shield controller, it's the 2019 remote control. Shaped
like an actual remote control.
https://www.amazon.com/NVIDIA-Motion-Activated-Backlit-Buttons-Customizable/dp/B08GNHJB6X/
- What is already being changed? Are you talking about future RetroArch
development or referring to the "Menu Swap OK and Cancel" option or
something else?
On Android at least (similar to Windows, Xbox, Linux, Mac, and most things
besides Nintendo, even in Japan nowadays), Xbox style is the default.
RetroArch seemed to follow that default for me, with a Shield controller,
Xbox controller, etc., it works as expected. A/bottom button confirms,
B/right button backs out.
Yes, the option in RetroArch is called "Menu Swap OK and Cancel buttons"
and in my setup it's "ON" by default, but that seems like semantics. "ON"
being the default means means Xbox layout is "standard" (which makes sense
on Android too).
With the Shield remote, given the above, to at least be functional in the
UI, it'd make sense IMO for the back button to actually mean back and the
selector button to actually select something. It seems less likely for
someone to actually play a game with this remote, but if they wanted to
play a Nintendo game, it'd make sense IMO to then remap it for that console
or game, though I'm not even convinced they'd want to much of the time, and
it'd have to be a per-game thing anyway, because gaming on this remote
would be weird.
One reason I could be wrong is if there is some intent for Nintendo or
old-Sony-in-Japan style to actually be the primary orientation even if
that's not the case right now. Even as someone who owns more Nintendo
consoles than anything, I'd be surprised at this.
Am I confused about anything above?
…On Fri, Jun 3, 2022 at 6:05 AM hizzlekizzle ***@***.***> wrote:
hmm, that's a tough call. While you're obviously correct that the current
result is unintuitive, the A/B swap is only there for the Shield controller
and it seems weird to change the mapping to work around something we're
already changing...
IMO, we would just not swap A/B by default and let users set it, but that
would certainly upset a lot of people, too. No perfect answer, I guess.
—
Reply to this email directly, view it on GitHub
<#839 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALPUBS66SLQNL4XF6ZQ5YTVNH7JFANCNFSM5XYDTXSQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I'd love for this to become a controller-specific configuration, because we've had this problem pretty much on every platform. It's been almost 2 years, what are your thoughts on just merging this one forwards, and reverting if it causes issues with the NVidea Sheild remote? |
The existing config used the back button on this remote as "A" and the center button as "B". In the default UI, this meant that you need to hit the back button to select an option and the center button to back out. This seemed backwards, so I swapped them.
My guess is that whoever uploaded this configuration was using Nintendo-style controls in their RetroArch UI. Since that wasn't the default in my setup, I don't think it should be the default here. I understand this is a weird case where the remote doesn't resemble a real controller, though, and maybe I'm wrong if the RetroArch default orientation ("Menu Swap OK and Cancel Buttons") changes in cases I'm not aware of.
I could probably go on about a deeper code change that might be a more correct fix that works in all cases, but I don't know that there's interest or that it'd be worth it, so I just proposed this.