Re: hid_nintendo Switch 2 Pro Controller support - where to start?

[Saihaj Johal <personal@sjohal.net>]

On Sunday, 6 July 2025 22:48:43 British Summer Time linux@emily.st wrote:
> On Sat, Jul 5, 2025, at 23:27, Aditya Garg wrote:
> > On 06-07-2025 12:18 am, Saihaj Johal wrote:
> >> Hello,
> >> I recently got a Nintendo Switch 2 Pro Controller that is not currently
> >> directly supported by the kernel like how the Switch 1 controllers are.
> >> Looking in "hid-ids.h", there is no product ID for the new controller
> >> (got
> >> 0x2069 from "lsusb -v"). The device class shows as miscellaneous device,
> >> and the controller does not show the player LEDs to show it is active
> >> (it only charges over USB, alongside showing in "lsusb" as well as
> >> showing as a USB audio device for the headphone jack on the bottom).
> >> However, I have managed to get it to work as a HID device using this
> >> website (https://
> >> handheldlegend.github.io/procon2tool/) which uses WebUSB to send the
> >> right
> >> commands to make the controller turn on fully. After enabling, this setup
> >> seemingly works with the existing evdev system, although with some
> >> bizarre
> >> changes like the left stick's up and down being reversed (at least in
> >> KDE's
> >> game controller settings). The first step would likely be to add the
> >> device ID to "hid-ids.h", but from there where should I go in order to
> >> perhaps work on full support? I assume anything would work on the things
> >> discovered already by the WebUSB enabler tool, however I am very new to
> >> C and kernel development in general.
> > 
> > Simply mailing the mailing list won't get you replies. You should also
> > email relevant maintainers.
> > 
> > Ccing them
> 
> Hi, in 2022 I spent some time customizing the existing `hid_nintendo` driver
> to add support for a few more first-party Nintendo controllers made for the
> Nintendo Switch. I no longer work on this, since my day job keeps me very
> busy, but I can try to share a little bit about the obstacles I
> encountered.
> 
> When I first encountered the `hid_nintendo` driver, it was written very
> specifically to handle the original first-party Nintendo Switch
> controllers, most specifically the Joy-Cons. Part of what I did was to
> attempt to generalize the driver somewhat to make it easier to add support
> for other kinds of controllers. I did **not** succeed in completing this
> work, but I did make enough progress to succeed in my goal of supporting
> the N64 and Genesis controllers. And I know that some people were
> successful in using the driver that I forked.
> 
> Although I was not directly involved in incorporating this code into the
> Linux kernel again, I am gratified that people found it useful enough to
> incorporate.
> 
> I don't really know to what extent it's going to be necessary to rework the
> existing driver, or whether it's appropriate to create a new driver for the
> second generation of the Nintendo Switch input peripherals. Since this is a
> new generation of hardware device, there may be some differences in how it
> communicates over USB or Bluetooth. That is a bit beyond my knowledge, and
> I don't know if that information has been fully reverse engineered yet. It
> probably should not be taken for granted that what worked with the original
> Nintendo Switch controllers will work with the second generation as well. I
> would defer to the experts on this list.
> 
> Assuming that you want to experiment simply with trying to adapt the current
> driver to handle the newer peripherals, you will first need to modify the
> device IDs, as you've already discovered, in `hid-ids.h`. You will also
> need to modify the driver slightly to "claim" those peripherals (to tell
> the input subsystem which driver handles those device inputs). If you are
> successful in allowing the existing driver to talk to the new Switch 2
> controllers, then you must determine the numerical codes the controller
> emits when certain inputs are used and to map those to the actual buttons
> being used. Specifically, you must find a way to intercept the numerical
> codes that are coming from the controller, determine which inputs those
> control codes map to, and then calling the API of the kernel to create the
> correct inputs. I recall that when I did this, I think I read the codes out
> of the raw input device exposed by the kernel (somewhere in /dev/input, I
> think?), and then wrote down on paper which codes I saw when I pressed
> which buttons. Then I followed the existing pattern of how the kernel
> driver mapped those input codes to the existing kernel inputs. The current
> driver has many good examples of this in action.
> 
> **Take all this with a grain of salt.** I did this work years ago. I was
> never really a Linux kernel developer, and I am very rusty on how the
> driver worked. I can only remember the generalities, and I would again
> defer to the experts on this list to correct any mistakes I've
> inadvertently added here. I hope this helps since I was doing a very
> similar thing to what you're doing now. Best of luck.
Hi,
Thank you for the advice on trying to make the driver work. I have now 
attempted adding the IDs to the existing hid_nintendo driver, however to no 
avail. The driver definitely was doing something, considering the WebUSB 
enabler stopped working when that changed driver was in use, but not enough. 
It seems it would likely be best for the Switch 2 peripherals to be part of a 
new driver, as they seem to communicate in an entirely different way. From what 
I can gather from the documentation of the developer of the WebUSB enabler 
tool (https://docs.handheldlegend.com/s/link-zone/doc/usb-initialization-fisHohwe4m) the Switch 2 controllers, at least over USB, send a HID command to 
enable the controller, also containing the console's MAC address (guess we 
could use all zeroes for the kernel driver?) probably to pair the controller 
to the console. Then, another HID command sets the player LED to make the 
controller fully functional. After that, however, it seems like it would 
function like a generic HID controller based on the behaviour with the enabler 
(so not much driver work needed there), although we would need to configure the 
inputs in this new driver to send the right buttons to the rest of the system.  
The documentation says some of the HID commands needed to make it work, but 
either there is more needed that the enabler does or I'm struggling with 
sending HID commands properly to the controller (trying hidapitester as well 
as just echo to /dev/hidraw6) , so I've hit a dead end, as the controller does 
nothing without those commands being sent. This would likely be something to 
pick up for someone who has the experience in working with raw HID commands. 
Thank you for your assistance,
Saihaj