In the version of hid-switchcon used in L4T-Switch(https://gitlab.com/switchroot/l4t-kernel-4.9) has the option to link joycons as 1 controller in the driver. Unfortunatly, this is needed if you want to use 2 joycons as one using kodi-game-libretro, and retroarch. Is there any chance we can get a patch for that feature for hid-joycon, which supports rumble, battery, and led changes? It would be nice to get all of these features in 1 driver, without having to have a complicated userspace application as a go between.

Hi,

Does the driver support third party Switch Pro controller? I bought 8BitDo SN30-Pro-Plus controller but the driver fails to recognized this driver. The specification of this controller is similar to the original Nintendo Switch Pro controller without Amiibo support. It has IMU sensor as well. I use the latest commit from your repository.

Product link:
https://www.8bitdo.com/sn30-pro-plus/

Error log:

[36616.594438] usb 1-7: USB disconnect, device number 3
[36809.509912] usb 1-10: new full-speed USB device number 4 using xhci_hcd
[36809.838635] usb 1-10: New USB device found, idVendor=057e, idProduct=2009, bcdDevice= 2.00
[36809.838640] usb 1-10: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[36809.838642] usb 1-10: Product: Pro Controller
[36809.838644] usb 1-10: Manufacturer: Nintendo Co., Ltd.
[36809.838646] usb 1-10: SerialNumber: 000000000001
[36809.859036] nintendo 0003:057E:2009.0009: hidraw5: USB HID v81.11 Joystick [Nintendo Co., Ltd. Pro Controller] on usb-0000:02:00.0-10/input0
[36810.198429] nintendo 0003:057E:2009.0009: using factory cal for left stick
[36810.214430] nintendo 0003:057E:2009.0009: using factory cal for right stick
[36810.262432] nintendo 0003:057E:2009.0009: using factory cal for IMU
[36810.350446] nintendo 0003:057E:2009.0009: controller MAC = E4:17:D8:E0:96:7F
[36810.881949] nintendo 0003:057E:2009.0009: Failed to set home LED dflt; ret=-110
[36810.881955] nintendo 0003:057E:2009.0009: Failed to create leds; ret=-110
[36810.882364] nintendo 0003:057E:2009.0009: probe - fail = -110
[36810.882388] leds 0003:057E:2009.0009:home: Setting an LED's brightness failed (-38)
[36810.882433] leds 0003:057E:2009.0009:player4: Setting an LED's brightness failed (-38)
[36810.882470] leds 0003:057E:2009.0009:player3: Setting an LED's brightness failed (-38)
[36810.882504] leds 0003:057E:2009.0009:player2: Setting an LED's brightness failed (-38)
[36810.882539] leds 0003:057E:2009.0009:player1: Setting an LED's brightness failed (-38)

3rd Party Pro Controller SP5248LED (NYYXI CHAOS) with a Ubunti 23.10 in N100 Mini PC (with windows11 and yuzu works well)

Compiled with https://github.com/nicman23/dkms-hid-nintendo (wait please) and this repo (hid source files related) in order to simplify testing

root@nuci:/usr/src# git clone https://github.com/nicman23/dkms-hid-nintendo
Clonando en 'dkms-hid-nintendo'...
remote: Enumerating objects: 410, done.
remote: Counting objects: 100% (48/48), done.
remote: Compressing objects: 100% (28/28), done.
remote: Total 410 (delta 30), reused 23 (delta 20), pack-reused 362
Recibiendo objetos: 100% (410/410), 688.65 KiB | 3.02 MiB/s, listo.
Resolviendo deltas: 100% (72/72), listo.
root@nuci:/usr/src# cd dkms-hid-nintendo/
root@nuci:/usr/src#for i in hid-ids.h  hid-nintendo.c  hidraw.c  uhid.c
do
        wget https://raw.githubusercontent.com/DanielOgorchock/linux/ogorchock/drivers/hid/$i -O src/$i
done
root@nuci:/usr/src/dkms-hid-nintendo# dkms build nintendo -v 3.0 --force                                                                                        Deprecated feature: REMAKE_INITRD (/var/lib/dkms/nintendo/3.0/source/dkms.conf)
Deprecated feature: REMAKE_INITRD (/etc/dkms/framework.conf)
Sign command: /usr/bin/kmodsign
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der

Building module:
Cleaning build area...
make -j4 KERNELRELEASE=6.5.0-17-generic -C /lib/modules/6.5.0-17-generic/build M=/var/lib/dkms/nintendo/3.0/build/src modules...
Signing module /var/lib/dkms/nintendo/3.0/build/src/hid-nintendo.ko
Cleaning build area...
root@nuci:/usr/src/dkms-hid-nintendo# rmmod hid_nintendo
root@nuci:/usr/src/dkms-hid-nintendo# modprobe -a /lib/modules/6.5.0-17-generic/updates/dkms/hid-nintendo.ko.zst

Power up the controller

feb 22 11:53:31 nuci kernel: nintendo 0005:057E:2009.0006: unknown main item tag 0x0
feb 22 11:53:31 nuci kernel: nintendo 0005:057E:2009.0006: hidraw0: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on c8:8a:d8:11:d0:51
feb 22 11:53:35 nuci kernel: nintendo 0005:057E:2009.0006: failed reading SPI flash; ret=-110
feb 22 11:53:35 nuci kernel: nintendo 0005:057E:2009.0006: using factory cal for left stick
feb 22 11:53:37 nuci kernel: nintendo 0005:057E:2009.0006: failed reading SPI flash; ret=-110
feb 22 11:53:37 nuci kernel: nintendo 0005:057E:2009.0006: using factory cal for right stick
feb 22 11:53:39 nuci kernel: nintendo 0005:057E:2009.0006: failed reading SPI flash; ret=-110
feb 22 11:53:39 nuci kernel: nintendo 0005:057E:2009.0006: Failed to read left stick cal, using dflts; e=-110
feb 22 11:53:41 nuci kernel: nintendo 0005:057E:2009.0006: failed reading SPI flash; ret=-110
feb 22 11:53:41 nuci kernel: nintendo 0005:057E:2009.0006: Failed to read right stick cal, using dflts; e=-110
feb 22 11:53:43 nuci kernel: nintendo 0005:057E:2009.0006: failed reading SPI flash; ret=-110
feb 22 11:53:43 nuci kernel: nintendo 0005:057E:2009.0006: using factory cal for IMU
feb 22 11:53:45 nuci kernel: nintendo 0005:057E:2009.0006: failed reading SPI flash; ret=-110
feb 22 11:53:45 nuci kernel: nintendo 0005:057E:2009.0006: Failed to read IMU cal, using defaults; ret=-110
feb 22 11:53:45 nuci kernel: nintendo 0005:057E:2009.0006: Unable to read IMU calibration data
feb 22 11:53:45 nuci kernel: ================================================================================
feb 22 11:53:45 nuci kernel: UBSAN: array-index-out-of-bounds in /var/lib/dkms/nintendo/3.0/build/src/hid-nintendo.c:905:11
feb 22 11:53:45 nuci kernel: index 0 is out of range for type 'u8 [*]'
feb 22 11:53:45 nuci kernel: CPU: 0 PID: 1709558 Comm: kworker/0:2 Tainted: G           OE      6.5.0-17-generic #17-Ubuntu
feb 22 11:53:45 nuci kernel: Hardware name:  /, BIOS 5.26 09/26/2023
feb 22 11:53:45 nuci kernel: Workqueue: events uhid_device_add_worker [uhid]
feb 22 11:53:45 nuci kernel: Call Trace:
feb 22 11:53:45 nuci kernel:  <TASK>
feb 22 11:53:45 nuci kernel:  dump_stack_lvl+0x48/0x70
feb 22 11:53:45 nuci kernel:  dump_stack+0x10/0x20
feb 22 11:53:45 nuci kernel:  __ubsan_handle_out_of_bounds+0xc6/0x110
feb 22 11:53:45 nuci kernel:  nintendo_hid_probe+0x432/0x1a80 [hid_nintendo]
feb 22 11:53:45 nuci kernel:  ? devres_open_group+0x53/0x1b0
feb 22 11:53:45 nuci kernel:  hid_device_probe+0x12d/0x1b0 [hid]
feb 22 11:53:45 nuci kernel:  really_probe+0x1c4/0x410
feb 22 11:53:45 nuci kernel:  __driver_probe_device+0x8c/0x180
feb 22 11:53:45 nuci kernel:  driver_probe_device+0x24/0xd0
feb 22 11:53:45 nuci kernel:  __device_attach_driver+0xcd/0x170
feb 22 11:53:45 nuci kernel:  ? __pfx___device_attach_driver+0x10/0x10
feb 22 11:53:45 nuci kernel:  bus_for_each_drv+0x94/0xf0
feb 22 11:53:45 nuci kernel:  __device_attach+0xb6/0x1d0
feb 22 11:53:45 nuci kernel:  device_initial_probe+0x13/0x20
feb 22 11:53:45 nuci kernel:  bus_probe_device+0x9f/0xb0
feb 22 11:53:45 nuci kernel:  device_add+0x50b/0x700
feb 22 11:53:45 nuci kernel:  hid_add_device+0xf9/0x2d0 [hid]
feb 22 11:53:45 nuci kernel:  uhid_device_add_worker+0x19/0x80 [uhid]
feb 22 11:53:45 nuci kernel:  process_one_work+0x220/0x440
feb 22 11:53:45 nuci kernel:  worker_thread+0x4d/0x3f0
feb 22 11:53:45 nuci kernel:  ? _raw_spin_lock_irqsave+0xe/0x20
feb 22 11:53:45 nuci kernel:  ? __pfx_worker_thread+0x10/0x10
feb 22 11:53:45 nuci kernel:  kthread+0xef/0x120
feb 22 11:53:45 nuci kernel:  ? __pfx_kthread+0x10/0x10
feb 22 11:53:45 nuci kernel:  ret_from_fork+0x44/0x70
feb 22 11:53:45 nuci kernel:  ? __pfx_kthread+0x10/0x10
feb 22 11:53:45 nuci kernel:  ret_from_fork_asm+0x1b/0x30
feb 22 11:53:45 nuci kernel:  </TASK>
feb 22 11:53:45 nuci kernel: ================================================================================
feb 22 11:53:47 nuci kernel: nintendo 0005:057E:2009.0006: Failed to set report mode; ret=-110
feb 22 11:53:47 nuci kernel: nintendo 0005:057E:2009.0006: probe - fail = -110
feb 22 11:53:47 nuci kernel: nintendo: probe of 0005:057E:2009.0006 failed with error -110

I've been hearing all over the place that hid-nintendo was merged in for Linux 5.10. I'm about to update, but I can't seem to see the driver in the tree. What gives?

I've been using my Nintendo Switch Pro controller via bluetooth in Ubuntu 20.04. When using this driver, I noticed that it creates a joystick device for the controller, and one other separate device for the IMU. This has led to numerous issues in programs such as Retroarch and PCSX2 in which the 2nd player controller is always auto selected as the IMU device instead of a 2nd controller paired via bluetooth. Programs like PCSX2 will obey the order of joysticks as defined in /dev/input. This is what joysticks get listed when using this driver (as an example):

crw-rw----+  1 root input 13,   0 Jun  1 23:24 js0
crw-rw----   1 root input 13,   1 Jun  1 23:24 js1
crw-rw----+  1 root input 13,   2 Jun  1 23:31 js2
...
lrwxrwxrwx   1 root root        3 Jun  1 23:24 nintendo-controller-1 -> js0
lrwxrwxrwx   1 root root        3 Jun  1 23:31 xbox-controller-1 -> js2

Notice that my xbox controller becomes js2 instead of js1. This is because js1 is the IMU device.

The desirable behavior would be to not list the IMU as a separate joystick device. I've had to modify the driver and remove any reference to the IMU stuff as a workaround for the time being. I understand that the IMU is supposed to add the gyroscope capabilities of the controller, so would be nice to have working, but having the joysticks out of order is a show-stopper for the automation around a lot of my games, and most programs will try to use the joystick device as an actual controller.

Hi,

I compiled your latest code with rumble support using nintendo switch pro controller.

fftest shows the following capabilities

Device /dev/input/event16 opened
Features:

• Absolute axes: X, Y, RX, RY,
  [1B 00 00 00 00 00 00 00 ]
• Relative axes:
  [00 00 ]
• Force feedback effects types: Periodic, Rumble, Gain,
  Force feedback periodic effects: Square, Triangle, Sine,
  [00 00 00 00 00 00 00 00 00 00 03 07 01 00 00 00 ]
• Number of simultaneous effects: 16

Setting master gain to 75% ... OK
Uploading effect #0 (Periodic sinusoidal) ... OK (id 0)
Uploading effect #1 (Constant) ... Error: Invalid argument
Uploading effect #2 (Spring) ... Error: Invalid argument
Uploading effect #3 (Damper) ... Error: Invalid argument
Uploading effect #4 (Strong rumble, with heavy motor) ... OK (id 1)
Uploading effect #5 (Weak rumble, with light motor) ... OK (id 2)

When I tested #0, #4, #5, none of them provided any feedback. Do you know how I can test your code?

Hi,

First, thanks for your work, it's great to be able to use the controller. I am however getting an issue: the controller usually fails to stay connected with my HZ=1000 kernel, while it works fine on HZ=300. The blue LED lights up for a split second, then turns off, and the controller works for about 2-3 seconds before turning off. The input device still exists and is stuck to the values the controller had before disconnecting.

[ +11,657309] usb 4-1.2.1: new full-speed USB device number 34 using ehci-pci
[  +0,094944] usb 4-1.2.1: New USB device found, idVendor=057e, idProduct=2009, bcdDevice= 2.00
[  +0,000002] usb 4-1.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0,000001] usb 4-1.2.1: Product: Pro Controller
[  +0,000001] usb 4-1.2.1: Manufacturer: Nintendo Co., Ltd.
[  +0,000001] usb 4-1.2.1: SerialNumber: 000000000001
[  +0,001442] nintendo 0003:057E:2009.0016: probe - start
[  +0,000169] nintendo 0003:057E:2009.0016: hidraw8: USB HID v81.11 Joystick [Nintendo Co., Ltd. Pro Controller] on usb-0000:00:1d.0-1.2.1/input0
[  +0,270882] nintendo 0003:057E:2009.0016: detected USB controller
[  +0,437542] nintendo 0003:057E:2009.0016: synchronous send/receive timed out
[  +0,000002] nintendo 0003:057E:2009.0016: retrying sync send after timeout
[  +0,110998] nintendo 0003:057E:2009.0016: synchronous send/receive timed out
[  +0,000002] nintendo 0003:057E:2009.0016: send usb command failed; ret=-110
[  +0,000001] nintendo 0003:057E:2009.0016: requesting cal data
[  +0,027453] nintendo 0003:057E:2009.0016: calibration:
              l_x_c=1989 l_x_max=3507 l_x_min=420
              l_y_c=1936 l_y_max=3493 l_y_min=311
              r_x_c=1905 r_x_max=3425 r_x_min=301
              r_y_c=2105 r_y_max=3637 r_y_min=475
[  +0,000002] nintendo 0003:057E:2009.0016: requesting IMU cal data
[  +0,023996] nintendo 0003:057E:2009.0016: IMU calibration:
              a_o[0]=46 a_o[1]=-160 a_o[2]=242
              a_s[0]=16384 a_s[1]=16384 a_s[2]=16384
              g_o[0]=-7 g_o[1]=-36 g_o[2]=-91
              g_s[0]=13371 g_s[1]=13371 g_s[2]=13371
[  +0,000001] nintendo 0003:057E:2009.0016: setting controller report mode
[  +0,032013] nintendo 0003:057E:2009.0016: enabling rumble
[  +0,023989] nintendo 0003:057E:2009.0016: enabling IMU
[  +0,055999] nintendo 0003:057E:2009.0016: controller MAC = 04:03:D6:44:38:EB
[  +0,000002] nintendo 0003:057E:2009.0016: setting player leds
[  +0,024085] nintendo 0003:057E:2009.0016: setting home led brightness
[  +0,024022] input: Nintendo Switch Pro Controller as /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.2/4-1.2.1/4-1.2.1:1.0/0003:057E:2009.0016/input/input59
[  +0,000091] input: Nintendo Switch Pro Controller IMU as /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.2/4-1.2.1/4-1.2.1:1.0/0003:057E:2009.0016/input/input60
[  +0,000047] nintendo 0003:057E:2009.0016: probe - success
(about 1 second later, the controller player LEDs turn off, then turn back on, the blue light flashes, then about 2 seconds later the player LEDs turn off and it stops responding)
[ +15,323796] usb 4-1.2.1: USB disconnect, device number 34 (disconnected the cable)
[  +0,000051] nintendo 0003:057E:2009.0016: remove
[  +0,044432] nintendo 0003:057E:2009.0016: setting home led brightness
[  +0,000018] nintendo 0003:057E:2009.0016: setting player leds
[  +0,000015] nintendo 0003:057E:2009.0016: setting player leds
[  +0,000014] nintendo 0003:057E:2009.0016: setting player leds
[  +0,000014] nintendo 0003:057E:2009.0016: setting player leds

I've had no success trying to tune the timeouts to make it work, unfortunately. I've tried different values and turning up the number of retries to no change.

Thank you!

The codes for motion sensors don't match between Switch controllers and the DualShock/Dualsense: https://wiki.dolphin-emu.org/index.php?title=Motion_evdev.
While evdev has no standard for motion inputs (yet), the DualShock came first, and I don't see a reason why the codes for the Switch controllers shouldn't match.

hid-nintendo has some major problems (made worse by the fact that it's mainlined), but despite that, the maintainer doesn't have any form of activity on GitHub since September 2021.
It's perfectly fine if they don't have any spare time to work on it, but the status is still Maintained on the maintainer list, and it should be changed if it's not actually maintained anymore.

This fix 7811b8f sounds promising, but i'm not sure if i got this in my kernel.
I'm using ubuntu focal, kernel 5.15.0-41-generic
I don't see any version info in the syslog when connecting the controller

Is it only in the current official stable kernel 6.5.3?

I already reported those bugs to the hid-nintendo-dkms github page,but he said that I should report it there.
Those bugs happen when I connect the controller via usb or bluetooth.
I have the joycond-nicman23-git package installed (cause I don't want that the home controller blinks) and the dkms-hid-nintendo package.

So the first problem is that when I start some programs (for example ppsspp or cemu) and then the home button glows blue and I have to turn it off through steam even though joycond-nicman23-git should block that automatically.

The next problem is that the green leds at the bottom of the controller that shows which player I am also don't work correctly,sometimes it shows the player two led or player 3 led or player 4 led even though I am player 1.

The third problem is that I can't use my controller for the program sc-controller,when I try to connect it,then it just looks like this:

and it is not an sc-controller problem cause it works for other people and sc-controller supports hid devices.

The forth problem is that I have to hold the sync button down to reconnect it to bluetooth after disconnecting it.

This is my system info:

Hi,
Would it be possible to add in support for the official NES and SNES controllers?

@nadiaholmquist added them into an older version of this driver which worked fine, so I'm guessing any needed information can be found in there. (Links to the code: hid-ids.h, hid-nintendo.c)

Thanks for all the work put into this driver,
it's immensely appreciated!

It has been crucially like this ever since 5.16. My 8BitDo controller's Switch mode worked like a charm before, provided I would install manually the hid_nintendo module. I could get around it by shifting to its internal Xinput mode, but it lacks the gyro functions, whom exclusive to Switch mode.

I excavated through internet for finding somebody else with similar problem, and as this Reddit thread seems to indicate, this is a real confirmed issue. Although different controller, the description matches as precise my situation, right down into my dmesg reports outlining the LED's brightness failure. Most importantly, a kind user in the replies has brought a great synopsis about it, so be sure to read it before anything else.

https://libreddit.spike.codes/r/archlinux/comments/s3u7aa/sn30_pro_2_missing_from_devinputjs_after_516/

OS: ubuntu 24.04 with kernel 6.8.0-31

$ bluetoothctl

Agent registeredct to bluetoothd...[bluetooth]# N64 Controller
[N64 Controller]# info
Device ... (public)
Name: N64 Controller
Alias: N64 Controller
Class: 0x00002508 (9480)
Icon: input-gaming
Paired: yes
Bonded: yes
Trusted: no
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
UUID: Service Discovery Serve.. (00001000-0000-1000-8000-00805f9b34fb)
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: usb:v057Ep2019d0001

$ modinfo hid-nintendo

filename: /lib/modules/6.8.0-31-generic/kernel/drivers/hid/hid-nintendo.ko.zst
description: Driver for Nintendo Switch Controllers
author: Daniel J. Ogorchock [email protected]
author: Emily Strickland [email protected]
author: Ryan McClelland [email protected]
license: GPL
srcversion: 68AFB8BC216FA1ECC2AA9B7
alias: hid:b0005gv0000057Ep00002019
alias: hid:b0005gv0000057Ep0000201E
alias: hid:b0005gv0000057Ep00002017
alias: hid:b0005gv0000057Ep00002007
alias: hid:b0005gv0000057Ep00002006
alias: hid:b0003gv0000057Ep0000200E
alias: hid:b0005gv0000057Ep00002009
alias: hid:b0003gv0000057Ep00002019
alias: hid:b0003gv0000057Ep0000201E
alias: hid:b0003gv0000057Ep00002017
alias: hid:b0003g*v0000057Ep00002009
depends: ff-memless,hid
retpoline: Y
intree: Y
name: hid_nintendo
vermagic: 6.8.0-31-generic SMP preempt mod_unload modversions
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key: ...
sig_hashalgo: sha512
signature: ...

$ lsmod |grep nintendo

hid_nintendo 53248 0
ff_memless 24576 1 hid_nintendo
hid 184320 7 hid_nintendo,i2c_hid,hidp,usbhid,hid_multitouch,hid_generic,uhid

$ cat /usr/lib/udev/rules.d/89-joycond.rules

Keep steam from accessing hidraw for pro controller

Nintendo Switch Pro Controller over USB hidraw

KERNEL=="hidraw*", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="2009", MODE="0600", TAG-="uaccess", RUN+="/bin/setfacl -b /dev/%k"

Nintendo Switch Pro Controller over bluetooth hidraw

KERNEL=="hidraw*", KERNELS=="057E:2009", MODE="0600", TAG-="uaccess", RUN+="/bin/setfacl -b /dev/%k"

ACTION!="add", GOTO="joycond_end"
SUBSYSTEM!="input", GOTO="joycond_end"
KERNEL!="event*", GOTO="joycond_end"
ATTRS{id/vendor}=="057e", ATTRS{id/product}=="2009", ATTRS{name}!="Combined", ATTRS{name}!="Virtual", ATTRS{name}!="IMU", TAG+="joycond", MODE="0600"
ATTRS{id/vendor}=="057e", ATTRS{id/product}=="2006", ATTRS{name}!="Combined", ATTRS{name}!="Virtual", ATTRS{name}!="IMU", TAG+="joycond", MODE="0600"
ATTRS{id/vendor}=="057e", ATTRS{id/product}=="2007", ATTRS{name}!="Combined", ATTRS{name}!="Virtual", ATTRS{name}!="IMU", TAG+="joycond", MODE="0600"
ATTRS{id/vendor}=="057e", ATTRS{id/product}=="200e", ATTRS{name}!="Combined", ATTRS{name}!="Virtual", ATTRS{name}!="IMU", TAG+="joycond", MODE="0600"
ATTRS{id/vendor}=="057e", ATTRS{id/product}=="2017", ATTRS{name}!="Combined", ATTRS{name}!="Virtual", ATTRS{name}!="IMU", TAG+="joycond", MODE="0600"
ATTRS{id/vendor}=="057e", ATTRS{id/product}=="2019", ATTRS{name}!="Combined", ATTRS{name}!="Virtual", ATTRS{name}!="IMU", TAG+="joycond", MODE="0600"

LABEL="joycond_end"

evtest doesn't show the event of the controller and jstest shows nothing.

$ jstest-gtk

I'm opening this issue more as a way to research and discuss a solution, or find something I'm missing. While developing joycond-cemuhook, I'm noticing that specifically the Right Joycon IMU registers greater values for the axis -ABS_RZ (gyro Z- on dolphin) (using it as a wiimote, it's the motion as to move the pointer to the left).

An example of this issue would be that using a Pro Controller as a pointer won't lose center too quickly, but with a Right Joycon the small readings from me just holding it still will bring the pointer mostly towards the left and a bit down.

Edit: Tested on Dolphin using IMU directly and joycond-cemuhook and both give this same behavior.

I've tried using some sort of deadzone but even then as it reads rotation values these axes' positive and negative readings mismatch by a lot.

Could it be a calibration issue? Or am I missing something?

this is with the dkms module with both linux and linux-lts packages. It was previously stable with it (i have only every used the dkms module).

the modules complains for a time out. tested all of my commits, 2 different controllers (one pro, one joy r), downgrading bluez, removing imu

only report i get is:

nintendo 0005:057E:2009.000D: timeout waiting for input report
nintendo 0005:057E:2009.000E: unknown main item tag 0x0
nintendo 0005:057E:2009.000E: hidraw9: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on 00:19:86:00:00:47

___

upowerd[2007]: treating change event as add on /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-4/1-4.3/1-4.3:1.0/bluetooth/hci0/hci0:11/0005:057E:2009.000E/power_supply/nintendo_switch_controller_battery_0005:057E:2009.000E
upowerd[2007]: did not recognise type Unknown, please report
upowerd[2007]: did not recognise type Unknown, please report

edit: it seems to be the rumble, reverting support for it makes the bluetooth connection stable again

Under current 5.13.14 kernel version, after applying also current hid-nintendo patches version v15 (from HID: nintendo v15, Linux Input Mailing List), module drivers/hid/hid-nintendo.o fails to compile with those error messages:

  CALL    scripts/checksyscalls.sh
  CALL    scripts/atomic/check-atomics.sh
  DESCEND objtool
  CC [M]  drivers/hid/hid-nintendo.o
drivers/hid/hid-nintendo.c:406:9: error: ‘LED_FUNCTION_PLAYER’ undeclared here (not in a function); did you mean ‘LED_FUNCTION_POWER’?
  406 |         LED_FUNCTION_PLAYER "-1",
      |         ^~~~~~~~~~~~~~~~~~~
      |         LED_FUNCTION_POWER
drivers/hid/hid-nintendo.c:406:29: error: expected ‘}’ before string constant
  406 |         LED_FUNCTION_PLAYER "-1",
      |                             ^~~~
drivers/hid/hid-nintendo.c:405:55: note: to match this ‘{’
  405 | static const char * const joycon_player_led_names[] = {
      |                                                       ^
drivers/hid/hid-nintendo.c: In function ‘joycon_leds_create’:
drivers/hid/hid-nintendo.c:1880:58: error: expected ‘)’ before string constant
 1880 |                                       LED_FUNCTION_PLAYER "-5");
      |                                                          ^~~~~
      |                                                          )
drivers/hid/hid-nintendo.c:1877:38: note: to match this ‘(’
 1877 |                 name = devm_kasprintf(dev, GFP_KERNEL, "%s:%s:%s",
      |                                      ^
make[2]: *** [scripts/Makefile.build:273: drivers/hid/hid-nintendo.o] Error 1
make[1]: *** [scripts/Makefile.build:516: drivers/hid] Error 2
make: *** [Makefile:1862: drivers] Error 2

Steps to reproduce:

1. Fetch, uncompress and apply patches (dl as mbox from “Linux Input Mailing List”) to kernel linux-5.13.14;
2. Provide in kernel directory’s root .config file with option CONFIG_HID_NINTENDO=m (or =y, however not tested in my case);
3. Run make modules_prepare and make drivers/hid/hid-nintendo.o -- no jobs specified to avoid race condition. Full log for module compilation pasted above.

I can provide more information if required.

Thanks for support, best regards.

After some discussion in this wine bug report I was pointed toward hid-recorder, and indeed, hid-recorder (which reads /dev/hidraw3, the hid device assigned to my official switch pro controller), spews out a bunch of incoherent input data that seems to match the weird nonsensical data I got in some wine apps, particularly games using the windows HID APIs.

Since this tells me this isn't a wine-specific issue, I was hoping to get some guidance here. I'm using the hid-nintendo-dkms driver version 3.0.

the js/event devices strangely enough work. I'm wondering if this is because the raw HID data includes data from the IMU, which higher level systems like ev/js filter out? But that's just blind guessing, really.

Attached is a log from hid-recorder (which is part of libevdev/hid-tools)
abc.txt

I removed the battery from my Pro Controller, since I only ever use it over USB and I don't want to put additional strain on the battery by constantly charging it, in case I ever buy myself a BT radio.

However now it always reports the battery being empty, and gnome-shell is having a stroke as result of that.

Btw, I'm packaging hid-nintendo as a kmp module for openSUSE (dkms is discouraged). Any tips?
hardware/hid-nintendo
software.opensuse.org/download.html?project=hardware&package=hid-nintendo-kmp-default

OS: Linux Mint 20 (also updated to 20.3, but they have the same kernel)
Kernel: 5.13.0-28-generic

dkms operations work with no errors, but modprobe/insmod fails with: "ERROR: could not insert 'hid_nintendo': Exec format error". dmesg/journalctl output additionally shows: "module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 1, loc 0000000085ff9d82, val ffffffffc148a694".

So the USB system works 100% fine, but trying to get my pro controller to work with bluetooth is impossible.

It says that it has connected through bluetooth, but it is not recognized as an input device of any kind. My controller works if I open up steam, but steam uses it's own input driver system of course.

I can confidentially say that hid_nintendo has a problem with bluetooth.

EDIT: I realized that I should specify that I am using the gullikit king kong pro 2 controller in switch mode

Hello,

I am having an odd problem with hid driver. The controller is working fine wired but on bluetooth I have a "calibration" problem. Immediately upon connecting the calibration with sticks is fine but if you press any other button on controller, other then sticks it messes up axes so "UP" doesn't go all the way and center drifts (the video explains it better). The numbers in calibration tool goes all over the place.

Also it loses connection every 5 min, have been testing it to find out pattern why that happens.

Arch Linux with kernel 5.15.2, Hid-Nintendo 3.2 Try it also on different distros and linux kernels the problem persists..

https://reddit.com/link/qrwdke/video/9chgk9mui1z71/player

Thank you!

I've tried to use the joycond made by you in my Manjaro setup, but after failing, I've noticed that the hid-nintendo module is still not yet in the kernel officially. Since I'm sort of noob with any of the building stuff, are there any chances this gets ported temporarly as DKMS module? Or maybe could you provide instructions on how to handle something like that? Great works btw, best regards!

Normally, if you connect a Nintendo Switch Pro Controller via USB, it is automatically connected when turning the computer on.
If however the computer is suspended, when resuming the computer, the controller won't reconnect, even if you press a button. The ways to reconnect it are either:

• Press the sync button on the controller;
• Unplug and plug the USB cable;
• Reboot the computer.

Relevant logs from journalctl when suspending:

lug 11 00:39:44 nixos kernel: nintendo 0003:057E:2009.000F: compensating for 37 dropped IMU reports
lug 11 00:39:44 nixos kernel: nintendo 0003:057E:2009.000F: delta=504 avg_delta=13

When resuming:

lug 11 00:39:44 nixos kernel: leds 0003:057E:2009.000F:green:player-1: Setting an LED's brightness failed (-110)
lug 11 00:39:45 nixos kernel: leds 0003:057E:2009.000F:green:player-2: Setting an LED's brightness failed (-110)
lug 11 00:39:45 nixos kernel: leds 0003:057E:2009.000F:green:player-3: Setting an LED's brightness failed (-110)
lug 11 00:39:46 nixos kernel: leds 0003:057E:2009.000F:green:player-4: Setting an LED's brightness failed (-110)
lug 11 00:39:46 nixos kernel: leds 0003:057E:2009.000F:blue:player-5: Setting an LED's brightness failed (-110)

After pressing the sync button on the controller (still plugged in via USB):

lug 11 00:49:21 nixos kernel: usb 3-2: USB disconnect, device number 17
lug 11 00:49:22 nixos kernel: usb 3-2: new full-speed USB device number 18 using xhci_hcd
lug 11 00:49:22 nixos kernel: usb 3-2: New USB device found, idVendor=057e, idProduct=2009, bcdDevice= 2.10
lug 11 00:49:22 nixos kernel: usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
lug 11 00:49:22 nixos kernel: usb 3-2: Product: Pro Controller

...etcetera.

On my Switch Pro Controller (never updated the firmware) the mappings are correct with the evdev API, but not with the legacy joystick API.
The west button (X on Xbox, Y on Nintendo) is mapped as button 3, and the north button (Y on Xbox, X on Nintendo) is mapped as button 2. This should be the other way around. I never changed settings and I am not using joycond.

The A and B button are mapped correctly: the south button (A on Xbox, B on Nintendo) is mapped as button 0, and the east button (B on Xbox, A on Nintendo) is mapped as button 1.

I am using NixOS unstable, with Linux 5.14.15-zen1 x86_64, and dkms-hid-nintendo 3.2.

When connect nintendo pro gamepad through BT, in below function
the size is always 12, and the data[0] is always 63(JC_INPUT_BUTTON_EVENT 0x3F)
static int joycon_ctlr_handle_event(struct joycon_ctlr *ctlr, u8 *data,
int size)
{
int ret = 0;
bool match = false;
struct joycon_input_report *report;
int i;
hid_info(ctlr->hdev, "[wurc]joycon_ctlr_handle_event:size[%d] data[0] %d\n", size, data[0]);
for(i =0; i < size; i++)
{
hid_info(ctlr->hdev, "[wurc]data[%d]=[%x] \n", i, data[i]);
}
//hid_info(ctlr->hdev, "wurc - joycon_ctlr_handle_event---1\n");
if (unlikely(mutex_is_locked(&ctlr->output_mutex)) &&
ctlr->msg_type != JOYCON_MSG_TYPE_NONE) {
switch (ctlr->msg_type) {
case JOYCON_MSG_TYPE_USB:
if (size < 2)
break;
if (data[0] == JC_INPUT_USB_RESPONSE &&
data[1] == ctlr->usb_ack_match)
match = true;
break;
case JOYCON_MSG_TYPE_SUBCMD:
hid_info(ctlr->hdev, "[wurc]JOYCON_MSG_TYPE_SUBCMD-1:size[%d] data[0] %d\n", size, data[0]);
if (size < sizeof(struct joycon_input_report) ||
data[0] != JC_INPUT_SUBCMD_REPLY)
break;
hid_info(ctlr->hdev, "[wurc]JOYCON_MSG_TYPE_SUBCMD-2\n");
report = (struct joycon_input_report )data;
hid_info(ctlr->hdev, "[wurc]JOYCON_MSG_TYPE_SUBCMD-3: replyCmd[%d]-sendCmd[%d]\n", report->subcmd_reply.id, ctlr->subcmd_ack_match);
if (report->subcmd_reply.id == ctlr->subcmd_ack_match)
match = true;
break;
default:
break;
}
if (match) {
hid_info(ctlr->hdev, "[wurc]joycon_ctlr_handle_event ---2\n");
memcpy(ctlr->input_buf, data,
min(size, (int)JC_MAX_RESP_SIZE));
ctlr->msg_type = JOYCON_MSG_TYPE_NONE;
ctlr->received_resp = true;
wake_up(&ctlr->wait);
hid_info(ctlr->hdev, "[wurc]joycon_ctlr_handle_event ---3\n");
/ This message has been handled */
return 1;
}
}
And we have checked the data, it is like below
3f 00 00 08 70 85 5f 8c 70 7c 3f 8a
3f 00 00 08 60 85 5f 8c 70 7c 2f 8a
3f 00 00 08 70 85 4f 8c 60 7c 5f 8a
3f 00 00 08 70 85 6f 8c 70 7c 3f 8a
3f 00 00 08 70 85 6f 8c 60 7c 4f 8a
3f 00 00 08 70 85 7f 8c 60 7c 3f 8a
3f 00 00 08 70 85 7f 8c 70 7c 3f 8a
3f 00 00 08 70 85 6f 8c 70 7c 4f 8a
...

While connected through USB, nintendo gamepad can works well and its data is like below
the data size is always 64
21 96 91 00 80 00 98 f8 71 ec e7 7a 0b 90 10 28
80 00 00 18 67 00 39 00 92 03 00 40 00 40 00 40
f3 ff 09 00 02 00 e7 3b e7 3b e7 3b 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
..
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size**[64]** data[0] 129
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 129
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 129
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 33
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 33
nintendo 0003:057E:2009.0012: [wurc]joycon_ctlr_handle_event:size[64] data[0] 48

Do you know what cause gamepad send wrong data? it seems that the size should be 64 and the data content is also wrong in BT connection.

Hi @DanielOgorchock !

I've got a little question: i've got a pair of joycons that the system is recognizing as:

Left:

Input device ID: bus 0x5 vendor 0x57e product 0x2009 version 0x8001
Input device name: "Nintendo Switch Pro Controller"

Right:

Input device ID: bus 0x5 vendor 0x57e product 0x2009 version 0x8001
Input device name: "Nintendo Switch Pro Controller"

From hid-ids.h:

#define USB_VENDOR_ID_NINTENDO		0x057e
#define USB_DEVICE_ID_NINTENDO_WIIMOTE	0x0306
#define USB_DEVICE_ID_NINTENDO_WIIMOTE2	0x0330
#define USB_DEVICE_ID_NINTENDO_JOYCONL	0x2006
#define USB_DEVICE_ID_NINTENDO_JOYCONR	0x2007
#define USB_DEVICE_ID_NINTENDO_PROCON	0x2009  <---- are getting this global var
#define USB_DEVICE_ID_NINTENDO_CHRGGRIP	0x200E

So apparently there is no difference between them on product id or version id, and also as being recongized as Pro Controllers it complicates things because the SR/SL buttons of the joycons are not getting mapped/detected by the kernel.

evdev output for left:

Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 309 (BTN_Z)
    Event code 310 (BTN_TL)
    Event code 312 (BTN_TL2)
    Event code 314 (BTN_SELECT)
    Event code 317 (BTN_THUMBL)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value   1048
      Min   -32767
      Max    32767
      Fuzz     250
      Flat     500
    Event code 1 (ABS_Y)
      Value  -1026
      Min   -32767
      Max    32767
      Fuzz     250
      Flat     500
    Event code 16 (ABS_HAT0X)
      Value      0
      Min       -1
      Max        1
    Event code 17 (ABS_HAT0Y)
      Value      0
      Min       -1
      Max        1
  Event type 21 (EV_FF)
    Event code 80 (FF_RUMBLE)
    Event code 81 (FF_PERIODIC)
    Event code 88 (FF_SQUARE)
    Event code 89 (FF_TRIANGLE)
    Event code 90 (FF_SINE)
    Event code 96 (FF_GAIN)

evdev output for right:

Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 304 (BTN_SOUTH)
    Event code 305 (BTN_EAST)
    Event code 307 (BTN_NORTH)
    Event code 308 (BTN_WEST)
    Event code 311 (BTN_TR)
    Event code 313 (BTN_TR2)
    Event code 315 (BTN_START)
    Event code 316 (BTN_MODE)
    Event code 318 (BTN_THUMBR)
  Event type 3 (EV_ABS)
    Event code 3 (ABS_RX)
      Value   1048
      Min   -32767
      Max    32767
      Fuzz     250
      Flat     500
    Event code 4 (ABS_RY)
      Value  -1026
      Min   -32767
      Max    32767
      Fuzz     250
      Flat     500
  Event type 21 (EV_FF)
    Event code 80 (FF_RUMBLE)
    Event code 81 (FF_PERIODIC)
    Event code 88 (FF_SQUARE)
    Event code 89 (FF_TRIANGLE)
    Event code 90 (FF_SINE)
    Event code 96 (FF_GAIN)

But i've also saw in the code of hid-nintendo.c these lines:

(1624:1628)

switch (hdev->product) {
	case USB_DEVICE_ID_NINTENDO_PROCON:
		name = "Nintendo Switch Pro Controller";
		imu_name = "Nintendo Switch Pro Controller IMU";
		break;

That sets the device name but this took my attention too:
(483:501)

#define jc_type_is_joycon(ctlr) \
	(ctlr->hdev->product == USB_DEVICE_ID_NINTENDO_JOYCONL || \
	 ctlr->hdev->product == USB_DEVICE_ID_NINTENDO_JOYCONR || \
	 ctlr->hdev->product == USB_DEVICE_ID_NINTENDO_CHRGGRIP)
#define jc_type_is_procon(ctlr) \
	(ctlr->hdev->product == USB_DEVICE_ID_NINTENDO_PROCON)
#define jc_type_is_chrggrip(ctlr) \
	(ctlr->hdev->product == USB_DEVICE_ID_NINTENDO_CHRGGRIP)

/* Does this controller have inputs associated with left joycon? */
#define jc_type_has_left(ctlr) \
	(ctlr->ctlr_type == JOYCON_CTLR_TYPE_JCL || \
	 ctlr->ctlr_type == JOYCON_CTLR_TYPE_PRO)

/* Does this controller have inputs associated with right joycon? */
#define jc_type_has_right(ctlr) \
	(ctlr->ctlr_type == JOYCON_CTLR_TYPE_JCR || \
	 ctlr->ctlr_type == JOYCON_CTLR_TYPE_PRO)

Because later (at 1308 aprox the first recurrence) asks again if it's a joycon to report and set capability of the S buttons, which that seems to be the problem.

So, there is a way to get more information of the joycon in order to diferentiate them, additionaly to the product/version ids? How can i get this info? I see that you gets ctlr_type which i cannot find in the device info using the console so i assume there are more info that i'm not seeing.

Thanks in advance for reading!

OS: ArcoLinux
Kernel: 6.6.1-arch1-1
I have purchased third party joycons that used to work with hid-nintendo-dkms (which no longer builds after I installed the OS on a new machine, so not an option), but not with hid-nintendo. The joycons pair with bluetooth, but no program will recognise it's input.

This is the dmesg

[ 1269.995164] nintendo 0005:057E:2006.000C: unknown main item tag 0x0
[ 1269.995846] nintendo 0005:057E:2006.000C: hidraw4: BLUETOOTH HID v80.01 Gamepad [Joy-Con (L)] on b4:8c:9d:5b:88:04
[ 1270.060444] nintendo 0005:057E:2006.000C: using user cal for left stick
[ 1270.093730] nintendo 0005:057E:2006.000C: using factory cal for right stick
[ 1270.170519] nintendo 0005:057E:2006.000C: using user cal for IMU
[ 1270.370323] nintendo 0005:057E:2006.000C: controller MAC = 98:B6:E9:82:69:AE
[ 1270.387454] input: Nintendo Switch Left Joy-Con as /devices/pci0000:00/0000:00:08.3/0000:08:00.0/usb5/5-1/5-1:1.0/bluetooth/hci0/hci0:51/0005:057E:2006.000C/input/input37
[ 1270.387741] input: Nintendo Switch Left Joy-Con IMU as /devices/pci0000:00/0000:00:08.3/0000:08:00.0/usb5/5-1/5-1:1.0/bluetooth/hci0/hci0:51/0005:057E:2006.000C/input/input38
[ 1275.422776] nintendo 0005:057E:2006.000C: compensating for 4 dropped IMU reports
[ 1275.422786] nintendo 0005:057E:2006.000C: delta=40 avg_delta=7
[ 1276.559480] nintendo 0005:057E:2006.000C: joycon_enforce_subcmd_rate: exceeded max attempts
[ 1277.339341] nintendo 0005:057E:2006.000C: compensating for 5 dropped IMU reports
[ 1277.339353] nintendo 0005:057E:2006.000C: delta=50 avg_delta=7
[ 1278.273251] nintendo 0005:057E:2006.000C: compensating for 5 dropped IMU reports
[ 1278.273261] nintendo 0005:057E:2006.000C: delta=47 avg_delta=7
[ 1279.948901] nintendo 0005:057E:2006.000C: compensating for 4 dropped IMU reports
[ 1279.948911] nintendo 0005:057E:2006.000C: delta=46 avg_delta=8
[ 1283.176675] nintendo 0005:057E:2006.000C: compensating for 4 dropped IMU reports
[ 1283.176685] nintendo 0005:057E:2006.000C: delta=40 avg_delta=7
[ 1284.441706] nintendo 0005:057E:2006.000C: joycon_enforce_subcmd_rate: exceeded max attempts
[ 1290.104488] nintendo 0005:057E:2006.000C: compensating for 4 dropped IMU reports
[ 1290.104501] nintendo 0005:057E:2006.000C: delta=40 avg_delta=7
[ 1292.269456] nintendo 0005:057E:2006.000C: joycon_enforce_subcmd_rate: exceeded max attempts
[ 1295.391018] nintendo 0005:057E:2006.000C: compensating for 4 dropped IMU reports
[ 1295.391028] nintendo 0005:057E:2006.000C: delta=46 avg_delta=8

After this it keeps repeating the messages for compensating dropped IMU reports, delta avg_delta, joycon_enforce_subcmd indefinitelly, although I don't know if it's supposed to. If you would require any other log message let me know.

lsmod also says that nothing is using hid-nintendo while the joycons are connected, I don't know if it's useful

When using the Pro Controller in Bluetooth mode it will randomly disconnect after some time, it might last a few minutes or a few hours (usually its a couple of minutes), it seems random.
When using combined Joycons there is no issue, they work perfectly every time.
When using the Pro Controller in wired mode it works normally.
Tried pairing without joycond, with different Bluetooth adapters, nothing works.
Logs when the controller connects:

Jan 13 20:04:55 Archer kernel: Bluetooth: HIDP (Human Interface Emulation) ver 1.2
Jan 13 20:04:55 Archer kernel: Bluetooth: HIDP socket layer initialized
Jan 13 20:04:55 Archer bluetoothd[1386]: profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection info
Jan 13 20:04:55 Archer systemd[548]: Reached target Bluetooth.
Jan 13 20:04:58 Archer kernel: hid-generic 0005:057E:2009.0006: unknown main item tag 0x0
Jan 13 20:04:58 Archer kernel: input: Pro Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.4/1-5.1.4:1.0/bluetooth/hci0/hci0:1/0005:057E:2009.0006/input/input33
Jan 13 20:04:58 Archer kernel: hid-generic 0005:057E:2009.0006: input,hidraw5: BLUETOOTH HID v0.01 Gamepad [Pro Controller] on 8c:88:2b:40:00:f1
Jan 13 20:04:58 Archer kernel: nintendo 0005:057E:2009.0006: unknown main item tag 0x0
Jan 13 20:04:58 Archer kernel: nintendo 0005:057E:2009.0006: hidraw5: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on 8c:88:2b:40:00:f1
Jan 13 20:05:00 Archer kernel: nintendo 0005:057E:2009.0006: using factory cal for left stick
Jan 13 20:05:00 Archer kernel: nintendo 0005:057E:2009.0006: using factory cal for right stick
Jan 13 20:05:00 Archer kernel: nintendo 0005:057E:2009.0006: using user cal for IMU
Jan 13 20:05:00 Archer kernel: nintendo 0005:057E:2009.0006: controller MAC = 64:B5:C6:44:80:8B
Jan 13 20:05:00 Archer kernel: input: Nintendo Switch Pro Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.4/1-5.1.4:1.0/bluetooth/hci0/hci0:1/0005:057E:2009.0006/input/input34
Jan 13 20:05:00 Archer kernel: input: Nintendo Switch Pro Controller IMU as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.4/1-5.1.4:1.0/bluetooth/hci0/hci0:1/0005:057E:2009.0006/input/input35
Jan 13 20:05:00 Archer joycond[436]: DEVNAME=event257 ACTION=add DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.4/1-5.1.4:1.0/bluetooth/hci0/hci0:1/0005:057E:2009.0006/input/input34/event257
Jan 13 20:05:00 Archer joycond[436]: Creating new phys_ctlr for /dev/input/event257
Jan 13 20:05:00 Archer joycond[436]: Found Pro Controller
Jan 13 20:05:00 Archer joycond[436]: driver_name: Nintendo Switch Pro Controller
Jan 13 20:05:00 Archer joycond[436]: MAC: 64:B5:C6:44:80:8B
Jan 13 20:05:01 Archer joycond[436]: adding epoll_subscriber: fd=5
Jan 13 20:05:01 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 4 dropped IMU reports
Jan 13 20:05:01 Archer kernel: nintendo 0005:057E:2009.0006: delta=90 avg_delta=15

Logs when the controller disconnects:

Jan 13 20:06:29 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 4 dropped IMU reports
Jan 13 20:06:29 Archer kernel: nintendo 0005:057E:2009.0006: delta=78 avg_delta=14
Jan 13 20:06:33 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 5 dropped IMU reports
Jan 13 20:06:33 Archer kernel: nintendo 0005:057E:2009.0006: delta=78 avg_delta=11
Jan 13 20:06:36 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 5 dropped IMU reports
Jan 13 20:06:36 Archer kernel: nintendo 0005:057E:2009.0006: delta=79 avg_delta=11
Jan 13 20:06:41 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 5 dropped IMU reports
Jan 13 20:06:41 Archer kernel: nintendo 0005:057E:2009.0006: delta=77 avg_delta=11
Jan 13 20:06:50 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 5 dropped IMU reports
Jan 13 20:06:50 Archer kernel: nintendo 0005:057E:2009.0006: delta=78 avg_delta=11
Jan 13 20:06:53 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 5 dropped IMU reports
Jan 13 20:06:53 Archer kernel: nintendo 0005:057E:2009.0006: delta=78 avg_delta=11
Jan 13 20:06:58 Archer kernel: nintendo 0005:057E:2009.0006: timeout waiting for input report
Jan 13 20:06:58 Archer joycond[436]: Lone controller paired
Jan 13 20:06:58 Archer joycond[436]: DEVNAME=event257 ACTION=remove DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.4/1-5.1.4:1.0/bluetooth/hci0/hci0:1/0005:057E:2009.0006/input/input34/event257

Would it be possible to support the official Taiko controller for the Nintendo Switch?

mai 06 02:20:06 kernel: usb 1-4: new full-speed USB device number 7 using xhci_hcd
mai 06 02:20:06 kernel: usb 1-4: New USB device found, idVendor=0f0d, idProduct=00f0, bcdDevice= 1.00
mai 06 02:20:06 kernel: usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
mai 06 02:20:06 kernel: usb 1-4: Product: Taiko Controller
mai 06 02:20:06 kernel: usb 1-4: Manufacturer: HORI CO.,LTD.
mai 06 02:20:06 kernel: input: HORI CO.,LTD. Taiko Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/0003:0F0D:00F0.0005/input/input25
mai 06 02:20:06 kernel: hid-generic 0003:0F0D:00F0.0005: input,hidraw3: USB HID v1.11 Gamepad [HORI CO.,LTD. Taiko Controller] on usb-0000:00:14.0-4/input0

I guess it should just act as a wired Switch Pro Controller.

I'm testing this https://github.com/libsdl-org/SDL/blob/SDL2/test/testhaptic.c

1. with a Xbox360 controller (clone)

INFO: 1 Haptic devices detected.
INFO: Device: Microsoft X-Box 360 pad
INFO:    Supported effects [16 effects, 16 playing]:
INFO:       sine
INFO:       triangle
INFO:       left/right
INFO:    Supported capabilities:
INFO:       gain
INFO: 
Uploading effects
INFO:    effect 0: Sine Wave
INFO:    effect 1: Left/Right
INFO: 
Now playing effects for 5 seconds each with 1 second delay between
INFO:    Playing effect 0
INFO:    Playing effect 1

2. Switch Pro Controller (clone)

INFO: 1 Haptic devices detected.
INFO: Device: Nintendo Switch Pro Controller
INFO:    Supported effects [16 effects, 16 playing]:
INFO:       sine
INFO:       triangle
INFO:       left/right
INFO:    Supported capabilities:
INFO:       gain
INFO: 
Uploading effects
INFO:    effect 0: Sine Wave
INFO:    effect 1: Left/Right
INFO: 
Now playing effects for 5 seconds each with 1 second delay between
INFO:    Playing effect 0
INFO:    Playing effect 1

With Xbox360 controller the effect 0 does nothing, but the effect 1 works
With Switch controller the effect 0 works but effect 1 does nothing

So in the actual game i don't get rumble with the Switch Controller, but with the Xbox360 i do.

Not sure if these effects are defined in SDL code or hid_nintendo

i'm using debian 11 with kernel 5.10
when i try to connect the switch pro controller with blueman or 'bt-device -c 70:F0:xx:xx:xx:9D' i get this in the syslog:

Dec 28 18:44:11 zort bluetoothd[9953]: profiles/input/device.c:control_connect_cb() connect to 70:F0:xx:xx:xx:9D: Host is down (112)
Dec 28 18:44:41 zort bluetoothd[9953]: profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection info
Dec 28 18:44:42 zort bluetoothd[9953]: profiles/input/device.c:control_connect_cb() connect to 70:F0:xx:xx:xx:9D: Permission denied (13)
Dec 28 18:44:56 zort bluetoothd[9953]: profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection info
Dec 28 18:44:57 zort bluetoothd[9953]: profiles/input/device.c:control_connect_cb() connect to 70:F0:xx:xx:xx:9D: Permission denied (13)
Dec 28 18:47:37 zort bluetoothd[9953]: profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection info

(when i press the bt button on the back)

does the controller reply with 'denied' so that probably means it doesn't want to be used with linux?

I've tested a pair of joycons and a pro controller. When using their gyro information, all of them end up reporting a single revolution as a single revolution plus about 30-45 degrees. Since offset is almost exactly the same for every tested device, I have to guess that default gyro resolution is incorrect.

to reconnect my switch pro controller i need to long press the small button and manually connect from the pc.

not sure if userland or this module issue but a ps3 controller i also have does not exhibit the issue

also
nicman23/dkms-hid-nintendo#39

I believe this is merged into linux but opening an issue here since it was mentioned in https://github.com/DanielOgorchock/joycond

I am using gulikit king kong controller with nintendo switch mode, but when I connect it to my computer, it freezes. There was once I upgraded the kernel (linux-zen) without reboot and it seemed to work fine, I guess some modules wasn't modprobed then it will work fine (no freeze) and detected a pro controller in yuzu but I am not sure which module.

5月 03 21:43:08 mi kernel: hid-generic 0005:045E:02E0.0006: unknown main item tag 0x0
5月 03 21:43:08 mi kernel: input: Pro Controller as /devices/pci0000:00/0000:00:08.1/0000:02:00.3/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:1/0005:045E:02E0.0006/input/input21
5月 03 21:43:08 mi kernel: hid-generic 0005:045E:02E0.0006: input,hidraw5: BLUETOOTH HID v9.03 Gamepad [Pro Controller] on 80:30:49:10:6b:d0

I got that log when I connect it through bluetooth, but on wired the computer freeze and keyboard caps lock led kept blinking.

Not sure if this is related but I got quite a bit of it in the journalctl logs.

Failed to find catalog entry: Invalid argument

uname -a

Linux mi 5.17.5-zen1-1-zen #1 ZEN SMP PREEMPT Wed, 27 Apr 2022 20:56:14 +0000 x86_64 GNU/Linux

I am not quite sure how to figure out what causes the computer to freeze but it happens after I changed the mode to switch controller, IIRC last time I saw something related to failed to probe ... mentioning nintendo in the journalctl but I can't it anymore.

If any more details is needed, feel free to say what information is needed, I guess it won't be easy to reproduce without the same hardware.

There are 4 modes for the controller, switch, xinput, dinput, android and switch is the only one that freezes the computer.

Hi, I installed the driver via the dkms module but connecting the controller via bluetooth fails with the following error messages in the kernel log

[ 8274.330816] nintendo 0005:057E:2009.0006: unknown main item tag 0x0
[ 8274.331071] nintendo 0005:057E:2009.0006: hidraw2: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on xx:xx:xx:xx:xx:xx
[ 8276.544262] nintendo 0005:057E:2009.0006: controller MAC = 80:A5:03:61:63:25
[ 8277.054077] nintendo 0005:057E:2009.0006: Failed to set home LED dflt; ret=-110
[ 8277.054085] nintendo 0005:057E:2009.0006: Failed to create leds; ret=-110
[ 8277.054400] nintendo 0005:057E:2009.0006: probe - fail = -110
[ 8277.558071] leds 0005:057E:2009.0006:home: Setting an LED's brightness failed (-110)
[ 8278.062004] leds 0005:057E:2009.0006:player4: Setting an LED's brightness failed (-110)
[ 8278.566018] leds 0005:057E:2009.0006:player3: Setting an LED's brightness failed (-110)
[ 8279.070042] leds 0005:057E:2009.0006:player2: Setting an LED's brightness failed (-110)
[ 8279.574077] leds 0005:057E:2009.0006:player1: Setting an LED's brightness failed (-110)

(Same issue as previously reported here: nicman23/dkms-hid-nintendo#4 )

Edit: I'm using a generic pro controller

I'm not sure of what exactly the problem is, since the controller works fantastically on Steam,
but logs seem to indicate the controller doesn't report its vendor or product id correctly in some way so the module isn't assigned to the controller?
I'm not familiar with the inner workings of the kernel so don't take my guess too seriously.
I've tried force loading the module with Steam closed before connecting the controller but no dice.
It may be a problem with my setup, I'm not too sure. If it's relevant, the SKU for the controller is 1513552-01

Relevant journal log (force loaded the module before just in case):

Oct 15 14:38:26 olympus kernel: hid_nintendo: loading out-of-tree module taints kernel.
Oct 15 14:38:26 olympus kernel: hid_nintendo: module verification failed: signature and/or required key missing - tainting kernel
Oct 15 14:38:26 olympus sudo[11670]: pam_unix(sudo:session): session closed for user root
Oct 15 14:38:26 olympus audit[11670]: USER_END pid=11670 uid=0 auid=1000 ses=2 msg='op=PAM:session_close grantors=pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/2 res=success'
Oct 15 14:38:26 olympus audit[11670]: CRED_DISP pid=11670 uid=0 auid=1000 ses=2 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/2 res=success'
Oct 15 14:38:26 olympus kernel: audit: type=1106 audit(1602794306.566:332): pid=11670 uid=0 auid=1000 ses=2 msg='op=PAM:session_close grantors=pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/2 res=success'
Oct 15 14:38:26 olympus kernel: audit: type=1104 audit(1602794306.566:333): pid=11670 uid=0 auid=1000 ses=2 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/2 res=success'
Oct 15 14:38:41 olympus kernel: hid-generic 0005:0000:0000.000B: unknown main item tag 0x0
Oct 15 14:38:41 olympus kernel: input: Lic Pro Controller as /devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-10/1-10:1.0/bluetooth/hci0/hci0:256/0005:0000:0000.000B/input/input46
Oct 15 14:38:41 olympus kernel: hid-generic 0005:0000:0000.000B: input,hidraw6: BLUETOOTH HID v0.01 Gamepad [Lic Pro Controller] on 1c:4d:70:05:73:72

Relevant Steam log entry:

Local Device Found
  type: 057e 2009
  path: /dev/hidraw6
  serial_number: 30:31:7d:12:1a:34 - 0
  Manufacturer:
  Product:      Lic Pro Controller
  Release:      0
  Interface:    -1

CApplicationManagerPopulateThread took 582 milliseconds to initialize (will have waited on CAppInfoCacheReadFromDiskThread)
Installing breakpad exception handler for appid(steam)/version(1602115886)
Proceed to auto login

** (steam:7543): WARNING **: 14:20:45.262: Could not initialize NMClient /org/freedesktop/NetworkManager: The name org.freedesktop.NetworkManager was not provided by any .service files
Switch: Bluetooth
!! Steam controller device opened for index 0.
Steam Controller reserving XInput slot 0
Installing breakpad exception handler for appid(steam)/version(1602115886)
Installing breakpad exception handler for appid(steam)/version(1602115886)
Controller 0 connected, configuring it now...
Installing breakpad exception handler for appid(steam)/version(1602115886)
Installing breakpad exception handler for appid(steam)/version(1602115886)
Switch Controller calibration:
  Sensor 0: bias -1, sensitivity 4.0000  Sensor 1: bias -1, sensitivity 4.0000  Sensor 2: bias 4097, sensitivity 4.0000  Sensor 3: bias 1, sensitivity 2.0000  Sensor 4: bias -10, sensitivity 2.0000  Sensor 5: bias 0, sensitivity 2.0000
!! Controller 0 attributes:
  Type: 38
  ProductID: 8201
  Serial: NLP30317d121a34
  Capabilities: 00856bff
  Firmware Version: 0
  Firmware Build Time: 2147483647 (Tue, 19 Jan 2038 03:14:07 GMT)
  Bootloader Build Time: 2147483647 (Tue, 19 Jan 2038 03:14:07 GMT)

As of right now, few PRs were merged into https://github.com/nicman23/dkms-hid-nintendo, but are not reflected by this repository. Those specifically include nicman23/dkms-hid-nintendo#25, nicman23/dkms-hid-nintendo#23 and not merged yet nicman23/dkms-hid-nintendo#27.

I'm on Arch linux with the latest updates.

I've tried building the dkms module manually, using the AUR, nothing works.

The hid_nintendo doesn't pick up the controller. It defaults to the hid-generic driver, and if I try to unbind it from the hid-generic driver it goes through.

Rebinding to the hid_nintendo driver though gives me this error:
-bash: echo: write error: No such device

So when I use the Kernel post 5.10, and doesn't have the Steam controller support on, this is what my machine use to recognize my Switch Pro controller right?

So an annoying thing is, I'm very used to Nintendo button layout, so when I'm playing, A means the right button for me.

But when I use the Linux controller support, it will take my A as B, B as A, as I've tried it in Enter the Gungeon binding.

If I use Steam's Pro Controller support, I can make it use the Nintendo Layout; but it's not really reliable since it sometimes load the profile too late and force me to restart the game.

If I can make it so the system would register my Input as it is, it would be so much easier for me.

Is that a thing already? Or is this now a feature request?

(Side note: I use Godot Engine to make things sometimes.
It doesn't work when using Steam input, probably because the compiled testing program didn't run through Steam;
when testing with Native Linux Pro Controller support, it works perfectly.
But in the Godot Input setting, the button is called "Dualshock Circle, Xbox B, Nintendo A",
Does that mean if the remapping works in all the other games, I could potentially revert it In Godot?
Not the big deal, but still kind of curious.)

I am getting these errors when trying to compile hid-joycon on l4t kernel 4.9:

drivers/hid/hid-joycon.c:223:1: error: initializer element is not constant
joycon_rumble_amplitudes[ARRAY_SIZE(joycon_rumble_amplitudes) - 1].amp;
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/hid/hid-joycon.c: In function ‘joycon_leds_create’:
drivers/hid/hid-joycon.c:1045:46: error: ‘LED_ON’ undeclared (first use in this function)
led->brightness = ((i + 1) <= input_num) ? LED_ON : LED_OFF;
^~~~~~
drivers/hid/hid-joycon.c:1045:46: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [scripts/Makefile.build:297: drivers/hid/hid-joycon.o] Error 1

I am not sure if there is something I am missing in the kernel config, but I am using the default L4T kernel config from switchroot, excepting the removal of hid-switchcon and the adding of hid-joycon. This happens on every version I have tested with led and rumble support. :(
I have tested version 4,5 and the latest version on git, with the work in progress IMU sensor code(Which had more errors, mainly for defined but unused variables.).

(Arch Linux, kernel 6.8.7-arch1-1)

I have been having troubles getting my 3rd party GuliKit Pro Controller to connect properly.

dmesg (dmesg -wH) displays this:

[  +0.266860] nintendo 0005:057E:2009.0014: timeout waiting for input report
[  +0.266241] nintendo 0005:057E:2009.0014: timeout waiting for input report
[  +0.266907] nintendo 0005:057E:2009.0014: timeout waiting for input report
[  +0.266646] nintendo 0005:057E:2009.0014: timeout waiting for input report
[  +0.266673] nintendo 0005:057E:2009.0014: timeout waiting for input report
[  +0.266701] nintendo 0005:057E:2009.0014: timeout waiting for input report
[  +0.266618] nintendo 0005:057E:2009.0014: timeout waiting for input report
[  +0.266686] nintendo 0005:057E:2009.0014: timeout waiting for input report

(etc. etc.)

it will occasionally say [ +0.000016] nintendo 0005:057E:2009.0014: joycon_enforce_subcmd_rate: exceeded max attempts after a while.

I will note that this error only occurs while using joycond (when not using joycond, the device is not recognized at all by the system, although it will be sending data on /dev/input/eventX). This cryptic dmesg error is the only mention of joycond that I could find, which only occurred once:

[  +0.053498] INFO: task joycond:34988 blocked for more than 122 seconds.
[  +0.000015]       Tainted: G           OE      6.8.7-arch1-1 #1
[  +0.000006] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  +0.000003] task:joycond         state:D stack:0     pid:34988 tgid:34988 ppid:34987  flags:0x00004002
[  +0.000013] Call Trace:
[  +0.000005]  <TASK>
[  +0.000012]  __schedule+0x3e6/0x1520
[  +0.000016]  ? srso_return_thunk+0x5/0x5f
[  +0.000014]  ? srso_return_thunk+0x5/0x5f
[  +0.000013]  schedule+0x32/0xd0
[  +0.000008]  schedule_timeout+0x151/0x160
[  +0.000012]  wait_for_completion+0x86/0x170
[  +0.000013]  __flush_work.isra.0+0x173/0x280
[  +0.000012]  ? __pfx_wq_barrier_func+0x10/0x10
[  +0.000015]  brightness_store+0x82/0xd0
[  +0.000015]  kernfs_fop_write_iter+0x136/0x1d0
[  +0.000015]  vfs_write+0x29e/0x470
[  +0.000018]  ksys_write+0x6f/0xf0
[  +0.000011]  do_syscall_64+0x83/0x170
[  +0.000012]  ? srso_return_thunk+0x5/0x5f
[  +0.000007]  ? srso_return_thunk+0x5/0x5f
[  +0.000009]  entry_SYSCALL_64_after_hwframe+0x78/0x80
[  +0.000010] RIP: 0033:0x70c09411a1a4
[  +0.000057] RSP: 002b:00007fff79254338 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
[  +0.000008] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 000070c09411a1a4
[  +0.000005] RDX: 0000000000000001 RSI: 00005d4b0e71ae20 RDI: 0000000000000006
[  +0.000005] RBP: 00005d4b0e71ae20 R08: 00007fff79254ba0 R09: 0000000000000001
[  +0.000004] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000001
[  +0.000004] R13: 0000000000000006 R14: 00007fff79254920 R15: 00007fff79254820
[  +0.000015]  </TASK>

I also had the error 110 that was mentioned elsewhere regarding a failed led light change (I haven't captured the exact message I got, so it may be unrelated).

I think that this issue would likely be solved by the most recent commit in this repo, which does not appear to be present in the most current Linux kernel. If that is the case, how would I build the kernel module in this repo and apply it?

[addendum: before someone mentions it, yes the kingkong2 does work in both its XBox controller and its direct input modes. However, as these modes do not have gyro (and xbox's rumble doesn't work too well), I would prefer to use the Switch mode over those.]

system is an ubuntu 22.04 jammy jellyfish (developement release) with gnome desktop.

I tried the hid-nintendo in two setups so far:

1. mainline kernel 5.15 with dkms-hid-nintendo as kernel extension (from nicman23s repository)
2. mainline kernel 5.16-rc1 with hid-nintendo built into the kernel
   To my knowledge both drivers are based on or directly derived from your code.

I can pair and connect the joy cons via bluetooth. Unfortunately after having 2 joy cons (left and right) connected the system will eventually freeze the desktop. The mouse cursor is still moving, but keyboard is unresponsive (even changing tty with ctrl+alt+F1...F8) and everything is frozen. I am forced to unplug power to shutdown/reboot the system.

By the way, I tried that before with 8bitdo sf30 pro controller in switch mode and its successfully contecting as switch pro controller and not hanging up. But with original joy cons from Nintendo it persistently freezes.

Also installed the joycond (and joycond-cemuhook).

As the issue even persists in the new mainline kernel 5.16-rc1 I felt the need to warn you about this issue as it might cause problems for others as well in the future using that kernel.

PS.: This issue is copy originally reported here

can we mask hidraw (talking out of my ass - i have 0 idea about the subsystem) so that steam does not mess with the controllers without a messy jail?

Is there a list of compatible 3rd party joycons? I tried some cheap ones I got from Five Below and they failed miserably (I assume there were many things missing in the hardware this driver expects).

(Copied from https://bugzilla.kernel.org/show_bug.cgi?id=216225)

The behavior of the Nintendo Switch Pro Controller player LED on Linux is this: the first time it's connected the first led turns on, the second time it's connected the first two LEDs (not just the second) turn on, the third time the first three LEDs (not just the third) turn on, the fourth time all LEDs (not just the fourth) turn on, and then it cycles back to the beginning.

This is completely different from the behavior when connected to the Switch console, where only one player LED ever turns on, and it's the one associated with the player (first LED for player one, second LED for player two...), not the number of times it's been connected.

Joycond does fix this, but there shouldn't be the need of using a daemon for something simple like this.

I don't know if from the kernel it's possible to get the "player number", but it would still be an improvement to only have one LED turning on.

Tested on a Pro Controller 050000007e0500000920000001800000, don't own a Joy-Con.

This have been observed both by me and some other people that last change actually causes Bluetooth to drop connection more often.