Note: this PR also contains issues with build-i686-linux. It won't compile properly due to "SDL_CONTROLLER_TYPE" interacts with Nintendo Switch controller types, but based on initial look: I believe this is related to using older version of SDL for i686-linux

As this PR is more or less a foundation for adding proper Button Labels support while viewing the keybind menu, this PR can't be pushed until that'd be solved.

I don't use gamepads when I can help it for FPSes, but as someone who prefers to use Circle as confirm and Cross as cancel on their DualSense, I approve of having an convenient option to swap confirm/cancel without altering in-gameplay controls.

I do wish to ask one question though: If the option to swap ABXY to BAYX and the option to just swap confirm and cancel are both separate and potentially can be both enabled at the same time, what happens if you do just that? Do you end up with a weird layout where the bottom button is confirm and the right is cancel, but the left and top buttons have their functions swapped? Or does one of them override the other?

I don't use gamepads when I can help it for FPSes, but as someone who prefers to use Circle as confirm and Cross as cancel on their DualSense, I approve of having an convenient option to swap confirm/cancel without altering in-gameplay controls.

I do wish to ask one question though: If the option to swap ABXY to BAYX and the option to just swap confirm and cancel are both separate and potentially can be both enabled at the same time, what happens if you do just that? Do you end up with a weird layout where the bottom button is confirm and the right is cancel, but the left and top buttons have their functions swapped? Or does one of them override the other?

SDL_HINT_GAMECONTROLLER_USE_BUTTON_LABELS will make the Face Button layout follow the Button labels. However, it has been shown (libsdl-org/SDL#6117) that it causes confusion down the road. Even more so in some sourceports who aren't aware of that hint. This is the major reason why SDL3 has switched to a Positional layout as opposed to labels. . it's also the true reason why useJapaneseLayout was created, a contingency plan for when fgsfdsfgs ports the project over to SDL3's.

Setting that hint (called "useNintendoLayout") defaults back to original default hint, and useJapaneseLayout will respects it.

The A/B/X/Y swapping is a good feature, however I feel like the "Japanese layout" thing can be just as well accomplished by just swapping the bindings on the Accept/Cancel buttons in the Extended Controls menu. I don't really want to add to the already complicated and confusing input logic just to make it very slightly easier to do, as it's already a pretty niche thing.
In any case, it would also be best for them to be in separate PRs.

The i686 problem is likely because the version of SDL2 available (or just used) for i686-linux is older and does not have this feature. It is in general best to guard these things with SDL_VERSION checks.

I won't add controller-specific deadzone settings, that's a bit too insane. It also depends on the specific Switch controller. I tested these settings against the joycons on my own early model Switch and it was fine. It's generally not possible to account for everything, which is why the deadzone is user-adjustable.

The A/B/X/Y swapping is a good feature, however I feel like the "Japanese layout" thing can be just as well accomplished by just swapping the bindings on the Accept/Cancel buttons in the Extended Controls menu. I don't really want to add to the already complicated and confusing input logic just to make it very slightly easier to do, as it's already a pretty niche thing. In any case, it would also be best for them to be in separate PRs.

Not a new feature, a necessity.

After playing with my Nintendo Switch controller, it follows the Nintendo layout in a literal way. I could rebind them to correct it, but since I often switch (no pun intended) controller types: it retroactively changes Player 1/2/3/4 bindings in the process. This is not ideal.

This is why useJapaneseLayout is a thing. What it really does is reversing "ACCEPT_BUTTON" / "CANCEL_BUTTON". Under the hood; it's really the same binding, this is only done for backwards compatibility.

I originally planned for the hardcoded approach, but based on feedback: I might revise it by opting for Button Input instead of an action.

note: this setup happened to be a standard in Nintendo Switch games, even in Nintendo's own games: Face Button swap only applies to Menus while Gameplay remains the same. SDL maintainers also suggested doing so.

I won't add controller-specific deadzone settings, that's a bit too insane. It also depends on the specific Switch controller. I tested these settings against the joycons on my own early model Switch and it was fine. It's generally not possible to account for everything, which is why the deadzone is user-adjustable.

Which is why I'm deciding whenever or not:

• Increase overall minimum deadzone to better account for first party controllers that wasn't calibrated or requires dedicated hardware (which is my case with Switch Pro Controller)
• change default In-Game Deadzone to something a bit higher. This option is far more likely for me

I won't add controller-specific deadzone settings, that's a bit too insane. It also depends on the specific Switch controller. I tested these settings against the joycons on my own early model Switch and it was fine. It's generally not possible to account for everything, which is why the deadzone is user-adjustable.

got good news to tell @fgsfdsfgs: the next SDL2/3 release candidate (or Steam Beta client as of this writing) will address this issue. I tested it using the main branch of SDL2 to confirm this specific problem is solved.

We can wait for the next release before making this PR ready for review.

The A/B/X/Y swapping is a good feature, however I feel like the "Japanese layout" thing can be just as well accomplished by just swapping the bindings on the Accept/Cancel buttons in the Extended Controls menu. I don't really want to add to the already complicated and confusing input logic just to make it very slightly easier to do, as it's already a pretty niche thing. In any case, it would also be best for them to be in separate PRs.

ok, after experimented with SDL_Get GamepadButtonLabel (SDL3 only): it's actually a lot easier to avoid making a complicated/confusing input logic by simply making this as our basis on Button UI Swap.

Example code:

        if (SDL_GetGamepadButtonLabel(gamepad, SDL_GAMEPAD_BUTTON_SOUTH) == SDL_GAMEPAD_BUTTON_LABEL_B) {
            flipped_buttons = true;
        } else {
            flipped_buttons = false;
        }

This gets rid of the need for Nintendo Switch-specific detection system as SDL_GetGamepadButtonLabel( covers that automatically. For that: I simplify the setup to set the foundation