This is a change impacting all platforms, right? The Changelog gives the idea we only changed this for iOS,.

Ah, that's a good point; thanks! If it sounds OK to you, I can add a new changelog item to reference the aliases being corrected and state that this is updated for both iOS and standalone.

Just added new changelog item to help clear up why this was fixed here. If you think this should be a second PR, let me know - I combined it together, just as the actual issue there impacts both iOS & Standalone :)

Do we need a new state? I wonder if we could actually create a similar pattern of what we dohere

Because the remapping seems to be done below, as we already did inSwitchProControllerHID.cs.

Maybe we would need to create aSwitchProController class. Which would be inherited bySwitchProControllerHID andSwitchProControlleriOS.

Currently, if you query buttonSouth, you'll get the A button's state, despite the fact buttonSouth is on the east on a Pro Controller. The new state maps this all correctly, such that buttonSouth will actually return the south face button.

The changes below are intended for situations when you want a button by label, regardless of where it is on the controller (e.g. some users will query this, and their UI in a tutorial will show "Press (A)").

If it makes this easier to land currently, I can split the changes to update aButton => buttonEast and friends into a new PR. This PR would then only focus on getting in the new state that rotates around the buttons for the Pro Controller.

Also agreed on the SwitchProController class as a root class; I'm just about to log off for the weekend, so I can make that change on Monday.

Just pushed change that adds newSwitchProController device :)

@vallerieknight-unity asking a lot here but a refactor like theSwitchProController forDualSense,DualShock,Xbox etc. is also much needed. We have so much boiler plate code as we otherwise get errors that specific controller features are not available on platform XY. We would expect that this is handled by the input system with an overall class per controller. Then if feature XY is not available on target XY it just does not perform the action and does not throw compile errors (e.g., PlayStation light bar). The same goes for creating actions and having to manually add targets to it due to different controller classes per platform. See the attached action we have for the select button on controllers to open a journal. You will notice we need several of the same controllers in there to make it work on all platforms the controller is used. Would bring a huge QoL improvement to using the input system.