Hello, On 7/7/25 8:22 AM, Saihaj Johal wrote: > On Sunday, 6 July 2025 22:48:43 British Summer Time linux@xxxxxxxx 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 > I have obtained various controllers--including the Pro Controller, GameCube adapter, Joy-Cons, and Charging Grip. Adding kernel support is on my todo list, though I want to bring up the SDL driver first for faster iteration and testing. Once that's working well enough, I plan to add support to the kernel. There's ongoing reverse engineering on a Discord I'm on, and it's different enough from the NS1 controllers that it's not going to be a simple process. Vicki
