linux-kernel - [Input] Wrong button mappings on PowerA USB gamepad

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2329F4E9-1A1B-4D8A-B853-F93A62FFC654@cox.net>
Date:   Wed, 09 Mar 2022 08:53:21 -0600
From:   Cameron <cameronghall@....net>
To:     linux-kernel@...r.kernel.org
CC:     linux-input@...r.kernel.org
Subject: [Input] Wrong button mappings on PowerA USB gamepad

Hello all,

I sent an email about this issue to the linux-input mailing list a week ago, but still haven't heard back, so I am sending it to the generic kernel mailing list.

I am using a PowerA USB wired Nintendo 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 wrote a small kernel module to correctly remap the buttons (code is here https://gist.github.com/camthesaxman/af7099505103a555518741b4083eaea8), but I would like to know more about how this kind of situation is handled in the input subsystem in order to create a proper patch.

Thanks,
Cameron