Update: Wrong button mappings reported by evdev with PowerA Nintendo Switch gamepad

[Cameron <cameronghall@cox.net>]

On Wed, 02 Mar 2022 12:45:17 -0600
Cameron <cameronghall@cox.net> wrote:

> Hello all,
> 
> This is my first time reporting a kernel issue, so please let me know
> if this is not the right place to report it. I am using a third party
> PowerA USB wired Switch controller on Void Linux. Games and
> applications are able to successfully detect and use the controller,
> however the button mapping is very wrong in every program I have
> tested. I tested this with evtest-qt to see what button values evdev
> is reporting. Since there appears to be no way to remap these from
> userspace, I suspect the problem lies in the kernel driver.
> 
> Pressing the two analog sticks (which should be BTN_THUMBL and
> BTN_THUMBR) incorrectly generate events for BTN_SELECT and BTN_START,
> and pressing the + and - buttons (which should be mapped to BTN_START
> and BTN_SELECT) instead result in BTN_TL2 and BTN_TR2 events.
> 
> The device in question (as reported by lsusb) is:
> Bus 001 Device 003: ID 20d6:a711 Core (Plus) Wired Controller
> and I am using kernel version 5.15.26_1 on Void Linux.
> 
> I understand that this gamepad is intended to be used with the
> Nintendo Switch console, so it may not be as HID compliant as, say, a
> Logitech. However the kernel has a standard for how these buttons are
> to be mapped, which the driver used for this gamepad appears to
> violate. https://www.kernel.org/doc/html/v4.13/input/gamepad.html
> Section 4.3 states: "All new gamepads are supposed to comply with
> this mapping. Please report any bugs, if they don’t."
> 
> I can provide more info if needed.
> 
> Thanks,
> Cameron

So, here's an update on this situation. I managed to hack around
this situation by writing a simple kernel module to override the button
mapping for this device. The code for the module can be found on my
GitHub here:
https://gist.github.com/camthesaxman/af7099505103a555518741b4083eaea8
I have almost zero experience with kernel development, so I don't know
how this kind of thing would be properly fixed in-tree (perhaps
something with hid-quirks.c?) and make a proper patch for the kernel.

Thanks,
Cameron