Change NSO N64 Controller mappings from hid-nx-dkms to upstream hid-nintendo

[0B001C]

The original mappings for the NSO N64 controller were created for hid-nx-dkms, an out-of-tree fork of the mainline hid-nintendo driver.

hid-nintendo has since gained support for the NSO controllers in Linux 6.8 while hid-nx-dkms was last updated for 6.1 and seems unmaintained. This open PR suggests that it doesn't even build against kernels >= 6.12 anymore.

Unfortunately the way the buttons are mapped to evdev events is different between these two drivers, requiring an update to the SDL mappings.

As I understand it this results in a breaking change since the GUIDs are the same. This change therefor trades of support for a legacy out-of-tree DKMS module against proper out-of-the-box mappings on modern kernels.

This PR only addresses the N64 controller. The NSO SFC / SNES and Mega Drive / Genesis Controllers are also affected but I don't have access to the hardware to verify any new mappings. The NSO Famicom / NES Controllers should be fine as-is.

[offalynne]

This change therefore trades of support for a legacy [..] module against [..] mappings on modern kernels

Thanks, this is always our preference. I will test with the SFC Online pad, as well.

[offalynne]

Present SFC NSO pad mappings seem good with hid-nintendo

[0B001C]

Present SFC NSO pad mappings seem good with hid-nintendo

https://github.com/torvalds/linux/blob/8560697b23dc2f405cb463af2b17256a9888129d/drivers/hid/hid-nintendo.c#L445C1-L457C3

static const struct joycon_ctlr_button_mapping snescon_button_mappings[] = {
	{ BTN_EAST,	JC_BTN_A,	},
	{ BTN_SOUTH,	JC_BTN_B,	},
	{ BTN_NORTH,	JC_BTN_X,	},
	{ BTN_WEST,	JC_BTN_Y,	},
	{ BTN_TL,	JC_BTN_L,	},
	{ BTN_TR,	JC_BTN_R,	},
	{ BTN_TL2,	JC_BTN_ZL,	},
	{ BTN_TR2,	JC_BTN_ZR,	},
	{ BTN_SELECT,	JC_BTN_MINUS,	},
	{ BTN_START,	JC_BTN_PLUS,	},
	{ /* sentinel */ },
};

vs.

https://github.com/emilyst/hid-nx-dkms/blob/e0d36613969b51564e1e5a48c82d40314abf97c7/hid-nx.c#L439C1-L451C3

static const struct nx_con_button_mapping snescon_button_mappings[] = {
	{ BTN_SOUTH,	NX_CON_BTN_A,		},
	{ BTN_EAST,	NX_CON_BTN_B,		},
	{ BTN_NORTH,	NX_CON_BTN_X,		},
	{ BTN_WEST,	NX_CON_BTN_Y,		},
	{ BTN_TL,	NX_CON_BTN_L,		},
	{ BTN_TR,	NX_CON_BTN_R,		},
	{ BTN_TL2,	NX_CON_BTN_ZL,		},
	{ BTN_TR2,	NX_CON_BTN_ZR,		},
	{ BTN_SELECT,	NX_CON_BTN_MINUS,	},
	{ BTN_START,	NX_CON_BTN_PLUS,	},
	{ /* sentinel */ },
};

hid-nx-dkms maps the face buttons to “Xbox-layout” according to their labels (effectively swapping A↔B and X↔Y) while hid-nintendo maps them according to their position.

So at least one of the two existing bluetooth-mappings should have it's buttons swapped the wrong way. (The one with the 0x8001 revision code in the GUID as well as the USB one if I understand the mapping guide correctly.)

I btw. tried to keep the N64 mapping as it was before (mapping b1 / B to b / SDL_GAMEPAD_BUTTON_EAST even though it is located to the top-left of the b0 / A button mapped as a / SDL_GAMEPAD_BUTTON_SOUTH).

[offalynne]

A>A, B>B is correct for N64, thanks for following the format

[offalynne]

@0B001C Can you confirm you actually saw 050000007e0500001920000001000000 as a GUID under this driver and the mapping matches, or did you copy the mapping across?

As I understand it this is the generic GUID and mapping seen through HID without a driver and thus should not use the updated driver mapping

Edit: I am unable to get the 01000000 suffix and as I recall the author of hid-nintendo deliberately tweaked a value to avoid this collision in SDL, I'm leaving it off

[0B001C]

Ah, sorry you are right, that id shouldn't have been modified in the commit.
The other two GUIDs (USB and BT via hid-nintendo) are what I actually saw with my controller and verified the mappings for.

As I understand it this is the generic GUID and mapping seen through HID without a driver and thus should not use the updated driver mapping

Edit: I am unable to get the 01000000 suffix and as I recall the author of hid-nintendo deliberately tweaked a value to avoid this collision in SDL I'm leaving it off

That's correct, there's even a comment explaining the reasoning for patching the hardware version wrt. SDL mapping compatibility:
https://github.com/torvalds/linux/blob/8560697b23dc2f405cb463af2b17256a9888129d/drivers/hid/hid-nintendo.c#L2663C1-L2669C5

[offalynne]

e7aecb6