We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Actually, the Switch Controller code has a special case to ignore the hint if the controller uses the GameCube form factor. Basically the (B) button on the GameCube controller is always assumed to be the B button since it has such a unique physical layout, and everything falls out from there.

Also, if respecting the hint were desirable, then it would also need to be taken into account in the Mayflash adapter controller binding, in SDL_gamecontrollerdb.h

Since the hint defaults to true anyway, I wonder if fixing it in the Switch path is worthwhile as well. I’m not sure how the Mayflash path would be fixed, but the main concern is the top/left/right/bottom position - the shapes are definitely weird but for games that might only care about location and not shape (some XNA games for example) it can get really disorienting, particularly if a developer ends up writing a fixed path for menu action sets exclusively (i.e. only swap A/B in menus).

Point being, I need a hint to turn this swap off, this hint’s name suggested it would be an appropriate fix.

Yeah, I'm debating whether to make the hint apply here. I think it sort of makes sense, if you presume a game knows about the GameCube layout and actually wants to swap buttons. Maybe we should use a GameCube specific hint?

What's the use case where an XNA game cares about location and not shape?

To name a few:

- Before the Echo explicitly maps the diamond buttons to directions, so without an option to turn this off, left and right are permanently swapped.
- Dust: An Elysian Tail, Dishwasher: Vampire Smile, Charlie Murder, and Salt & Sanctuary expect the left and top buttons to be primary attack buttons, while the right button is an extra attack button. With the swap forced, the more important attack button is moved to one of the outer buttons. Additionally, Dust already has separate action sets for menus and physical layout, so inserting GameCube behavior for the joystick GUID is trivial (FNA encourages querying vendor/product information through an extension).
- Flinthook and RetroArch specifically have toggles for Eastern/Western menu button options, adding an extra layer of confusion for GameCube users who just want to assume more common layouts and rebind to what they're already used to rebinding.

I'll happily take a second environment variable, whatever will guarantee that this patch will make it into revision control.

Argh, forgot about this because my search didn't include `RESPONDED` statuses.

This is still a pretty major breakage for FNA, but worst case I can revert this change in the fnalibs builds. But, that'd be a pretty microscopic undocumented change from upstream that pretty much nobody but us would know about.

I'm still up for both using the existing USE_BUTTON_LABELS variable as well as making a new variable for GameCube, whichever has a better chance of making it into 2.0.12 at the last minute (and of course, I can test whatever is chosen).

So I committed this:
https://hg.libsdl.org/SDL/rev/e6a2558ec791
but I think we'll need to modify it, because I don't think it matches the behavior of the Nintendo Switch GameCube form factor controllers. On those, both A and B and X and Y are swapped, but you're leaving Y alone and only swapping X and B.

I think that's the correct positional mapping, but I'll need to test those, so I'm going to back out your patch for 2.0.12 release.

The Switch GameCube controllers I believe show up as Switch Pro, so the mappings there will be different. Testing latest tip now to verify both swap modes.

Tested both modes, this patch should work! AFAIK the Switch GameCube controllers are a whole separate thing for SDL_hidapi_switch.c.

Okay, I made the hint work consistently for both the GameCube driver and Nintendo Switch controllers that have GameCube form factor:
https://hg.libsdl.org/SDL/rev/78d0bb6f3b8f

I'm leaving this open so we can address the Mayflash adapters after 2.0.12 ships.

This is now fixed for the Mayflash adapters as well:
https://hg.libsdl.org/SDL/rev/2ef60abd9132

Now that the gamecontroller mappings use the label hint directly in their bindings, do we need to remove the remap code from the GameCube driver to prevent double flipping?

No, the GameCube driver doesn't handle the mayflash adapter. They're distinct driver paths.