Compatibility with generic pro controllers

[Woazboat]

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: https://github.com/nicman23/dkms-hid-nintendo/issues/4 )

Edit: I'm using a generic pro controller

[rodolpheh]

I also have the same issue with a generic Pro Controller, here is the relevant dmesg messages :

[  175.268848] hid-generic 0005:057E:2009.0008: unknown main item tag 0x0
[  175.268961] input: Pro Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-14/1-14:1.0/bluetooth/hci0/hci0:256/0005:057E:2009.0008/input/input46
[  175.280499] hid-generic 0005:057E:2009.0008: input,hidraw5: BLUETOOTH HID v0.01 Gamepad [Pro Controller] on xx:xx:xx:xx:xx:xx
[  175.341003] nintendo 0005:057E:2009.0008: unknown main item tag 0x0
[  175.341138] nintendo 0005:057E:2009.0008: hidraw5: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on xx:xx:xx:xx:xx:xx
[  177.449401] nintendo 0005:057E:2009.0008: controller MAC = 62:E1:2A:CC:63:25
[  177.976426] nintendo 0005:057E:2009.0008: Failed to set home LED dflt; ret=-110
[  177.976428] nintendo 0005:057E:2009.0008: Failed to create leds; ret=-110
[  177.976641] nintendo 0005:057E:2009.0008: probe - fail = -110
[  178.509678] leds 0005:057E:2009.0008:home: Setting an LED's brightness failed (-110)
[  179.042939] leds 0005:057E:2009.0008:player4: Setting an LED's brightness failed (-110)
[  179.576166] leds 0005:057E:2009.0008:player3: Setting an LED's brightness failed (-110)
[  180.109424] leds 0005:057E:2009.0008:player2: Setting an LED's brightness failed (-110)
[  180.642676] leds 0005:057E:2009.0008:player1: Setting an LED's brightness failed (-110)
[  180.642772] nintendo: probe of 0005:057E:2009.0008 failed with error -110

Let me know if you need more information.

[Woazboat]

Okay, I think I know what the actual problem is. The generic chinese pro controller clone I'm using doesn't actually have an led under the home button unlike the real pro controller.

https://www.aliexpress.com/item/4000571346668.html

[Woazboat]

Connecting to the controller works after simply disabling the home LED in joycon_leds_create(), however none of the inputs seem to be recognized.

/* configure the home LED */
if (false && jc_type_has_right(ctlr)) {
//...

[13580.885490] hid-generic 0005:057E:2009.0003: unknown main item tag 0x0
[13580.885725] input: Pro Controller as /devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4:1.0/bluetooth/hci0/hci0:256/0005:057E:2009.0003/input/input28
[13580.886100] hid-generic 0005:057E:2009.0003: input,hidraw2: BLUETOOTH HID v0.01 Gamepad [Pro Controller] on xx:xx:xx:xx:xx:xx
[13580.891310] hid_nintendo: loading out-of-tree module taints kernel.
[13580.891409] hid_nintendo: module verification failed: signature and/or required key missing - tainting kernel
[13580.944392] nintendo 0005:057E:2009.0003: unknown main item tag 0x0
[13580.944585] nintendo 0005:057E:2009.0003: hidraw2: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on xx:xx:xx:xx:xx:xx
[13583.015320] nintendo 0005:057E:2009.0003: controller MAC = 80:A5:03:61:63:25
[13583.021817] input: Nintendo Switch Pro Controller as /devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4:1.0/bluetooth/hci0/hci0:256/0005:057E:2009.0003/input/input29
[13583.021945] input: Nintendo Switch Pro Controller IMU as /devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4:1.0/bluetooth/hci0/hci0:256/0005:057E:2009.0003/input/input30

[rodolpheh]

I tried the same, with the same result... I also have the same controller than you.

[Woazboat]

Changed the issue name since it seems like this is not a simple fix. I've tried to get my controller to produce HID input reports over bluetooth, but haven't been successful so far.

[dogtopus]

Okay, I think I know what the actual problem is. The generic chinese pro controller clone I'm using doesn't actually have an led under the home button unlike the real pro controller.

https://www.aliexpress.com/item/4000571346668.html

I know this is not hid-sony but IIRC they explicitly stated that they won't make extra effort supporting knockoffs that don't work already since there are just too many of then all with their own quirks.

(Well unless if your knockoff controller used some unsupported official method to select "supported features" like 3rd party PS4 controllers. In that case support definitely sounds possible if the dev is willing to do it. Again seems that hid-sony didn't really got the interest to do this for their supported devices. I think the Xbox controller driver did though.)

[DanielOgorchock]

There is a conversation in the hid-nintendo latest patchset thread on the linux-input mailing list discussing how to handle the generic clones.

I think supporting them will be tricky when they don't support the full interface, but maybe portions of the driver can be tweaked to fail gracefully without exiting the probe. The thing about that which makes me weary is if that ends up masking real errors on the official controllers.

[ludenticus]

After a whole system reinstall, fiddling with dkms modules and changing distro, I found finally found out here that it was a hardware-related issue. Such a shame, provided the quality of the clone.

Thanks anyway, @DanielOgorchock

[SimonDaniel21]

my pro controller clone also has the same issue, but works flawless with my android phone over bluetooth...

[jorants]

To add some information: I recently bought an off-brand pro controller that works perfectly fine on the switch and android as well. This one

Similar errors over bluetooth:

[ 5880.300160] nintendo 0005:057E:2009.0005: unknown main item tag 0x0
[ 5880.300363] nintendo 0005:057E:2009.0005: hidraw1: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on e4:70:b8:52:ec:79
[ 5884.359242] nintendo 0005:057E:2009.0005: failed reading SPI flash; ret=-110
[ 5884.359248] nintendo 0005:057E:2009.0005: using factory cal for left stick
[ 5886.385707] nintendo 0005:057E:2009.0005: failed reading SPI flash; ret=-110
[ 5886.385711] nintendo 0005:057E:2009.0005: using factory cal for right stick
[ 5888.412576] nintendo 0005:057E:2009.0005: failed reading SPI flash; ret=-110
[ 5888.412581] nintendo 0005:057E:2009.0005: Failed to read left stick cal, using dflts; e=-110
[ 5890.439234] nintendo 0005:057E:2009.0005: failed reading SPI flash; ret=-110
[ 5890.439241] nintendo 0005:057E:2009.0005: Failed to read right stick cal, using dflts; e=-110
[ 5892.465897] nintendo 0005:057E:2009.0005: failed reading SPI flash; ret=-110
[ 5892.465901] nintendo 0005:057E:2009.0005: using factory cal for IMU
[ 5894.492594] nintendo 0005:057E:2009.0005: failed reading SPI flash; ret=-110
[ 5894.492600] nintendo 0005:057E:2009.0005: Failed to read IMU cal, using defaults; ret=-110
[ 5894.492602] nintendo 0005:057E:2009.0005: Unable to read IMU calibration data
[ 5896.519246] nintendo 0005:057E:2009.0005: Failed to set report mode; ret=-110
[ 5897.052570] nintendo 0005:057E:2009.0005: Failed to enable rumble; ret=-110
[ 5897.052953] nintendo 0005:057E:2009.0005: probe - fail = -110
[ 5897.052978] nintendo: probe of 0005:057E:2009.0005 failed with error -110

When connecting over USB and switching to switch mode (it first pretends to be an XBOX controller) i get :

[ 6542.305622] usb 1-9: new full-speed USB device number 67 using xhci_hcd
[ 6542.428960] usb 1-9: device descriptor read/64, error -71
[ 6542.679072] usb 1-9: New USB device found, idVendor=057e, idProduct=2009, bcdDevice= 2.00
[ 6542.679074] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 6542.679075] usb 1-9: Product: Pro Controller
[ 6542.679076] usb 1-9: Manufacturer: Nintendo Co., Ltd.
[ 6542.679078] usb 1-9: SerialNumber: 000000000001
[ 6542.699657] nintendo 0003:057E:2009.0007: hidraw1: USB HID v81.11 Joystick [Nintendo Co., Ltd. Pro Controller] on usb-0000:00:14.0-9/input0
[ 6546.812296] nintendo 0003:057E:2009.0007: failed reading SPI flash; ret=-110
[ 6546.812297] nintendo 0003:057E:2009.0007: using factory cal for left stick
[ 6548.838972] nintendo 0003:057E:2009.0007: failed reading SPI flash; ret=-110
[ 6548.838974] nintendo 0003:057E:2009.0007: using factory cal for right stick
[ 6550.865644] nintendo 0003:057E:2009.0007: failed reading SPI flash; ret=-110
[ 6550.865645] nintendo 0003:057E:2009.0007: Failed to read left stick cal, using dflts; e=-110
[ 6552.892302] nintendo 0003:057E:2009.0007: failed reading SPI flash; ret=-110
[ 6552.892304] nintendo 0003:057E:2009.0007: Failed to read right stick cal, using dflts; e=-110
[ 6554.918961] nintendo 0003:057E:2009.0007: failed reading SPI flash; ret=-110
[ 6554.918964] nintendo 0003:057E:2009.0007: using factory cal for IMU
[ 6556.945626] nintendo 0003:057E:2009.0007: failed reading SPI flash; ret=-110
[ 6556.945628] nintendo 0003:057E:2009.0007: Failed to read IMU cal, using defaults; ret=-110
[ 6556.945629] nintendo 0003:057E:2009.0007: Unable to read IMU calibration data
[ 6558.972267] nintendo 0003:057E:2009.0007: Failed to set report mode; ret=-110
[ 6559.505642] nintendo 0003:057E:2009.0007: Failed to enable rumble; ret=-110
[ 6559.505822] nintendo 0003:057E:2009.0007: probe - fail = -110
[ 6559.505832] nintendo: probe of 0003:057E:2009.0007 failed with error -110
[ 6559.505858] usbcore: registered new interface driver usbhid
[ 6559.505859] usbhid: USB HID core driver

[hcsaustrup]

I just tested the same controller today on RetroPie, and got the same (kind of) result. The controller pairs up nicely through bluetooth, and is visible with the "jstest" app. The four numbered LEDs are blinking and none of the buttons seem to do anything at all. Again, the build quality seems quite nice, so it would be awesome if it worked :-/

[albfan]

Hi, I'm using a HORIPAD (aliexpress cheapest ones) and everything seems to be mapped correctly using dkms hid-nintendo, expect for:

ABS_RX which looks like only map the half of the movement.

Using generic hid driver, axis are correctly mapped so I supposed there was something incorrect here.

After add some traces on ABS_RX, ABS_RY, ABS_X and ABX_Y:

diff --git c/src/hid-nintendo.c i/src/hid-nintendo.c
index 5d47968..6f77fa6 100644
--- c/src/hid-nintendo.c
+++ i/src/hid-nintendo.c
@@ -1231,9 +1231,12 @@ static void joycon_parse_report(struct joycon_ctlr *ctlr,
                x = joycon_map_stick_val(&ctlr->left_stick_cal_x, raw_x);
                y = -joycon_map_stick_val(&ctlr->left_stick_cal_y, raw_y);
                /* report sticks */
+               hid_dbg(ctlr->hdev, "axis ABS_X: raw_x:%hu x=%ld\n",raw_x, x);
                input_report_abs(dev, ABS_X, x);
+               hid_dbg(ctlr->hdev, "axis ABS_Y: raw_y:%hu y=%ld\n",raw_y, y);
                input_report_abs(dev, ABS_Y, y);
 
+
                /* report buttons */
                input_report_key(dev, BTN_TL, btns & JC_BTN_L);
                input_report_key(dev, BTN_TL2, btns & JC_BTN_ZL);
@@ -1287,7 +1290,10 @@ static void joycon_parse_report(struct joycon_ctlr *ctlr,
                x = joycon_map_stick_val(&ctlr->right_stick_cal_x, raw_x);
                y = -joycon_map_stick_val(&ctlr->right_stick_cal_y, raw_y);
                /* report sticks */
+
+               hid_dbg(ctlr->hdev, "axis ABS_RX: raw_x:%hu x:%ld\n",raw_x, x);
                input_report_abs(dev, ABS_RX, x);
+               hid_dbg(ctlr->hdev, "axis ABS_RY: raw_y:%hu y:%ld\n",raw_y, y);
                input_report_abs(dev, ABS_RY, y);
 
                /* report buttons */

I see no major difference on input, but calibration is different:

[21098.090523] nintendo 0003:057E:2009.002C: using factory cal for left stick
[21098.090528] nintendo 0003:057E:2009.002C: requesting SPI flash data
[21098.113164] nintendo 0003:057E:2009.002C: using user cal for right stick
[21098.113176] nintendo 0003:057E:2009.002C: requesting SPI flash data
[21098.129168] nintendo 0003:057E:2009.002C: requesting SPI flash data
[21098.145237] nintendo 0003:057E:2009.002C: calibration:
               l_x_c=2020 l_x_max=3500 l_x_min=379
               l_y_c=2013 l_y_max=3573 l_y_min=535
               r_x_c=15 r_x_max=1251 r_x_min=-135
               r_y_c=1555 r_y_max=2900 r_y_min=-2336

Not sure where that info comes from, but see right cal comes from user.

I just use the calibration from left joycon and that just works. Well it needs a manual calibration later, but not it is centered.

diff --git i/src/hid-nintendo.c w/src/hid-nintendo.c
index 6f77fa6..800e4bd 100644
--- i/src/hid-nintendo.c
+++ w/src/hid-nintendo.c
@@ -768,7 +768,8 @@ static int joycon_request_calibration(struct joycon_ctlr *ctlr)
        }
 
        /* read the right stick calibration data */
-       ret = joycon_read_stick_calibration(ctlr, right_stick_addr,
+       ret = joycon_read_stick_calibration(ctlr, left_stick_addr,
                                            &ctlr->right_stick_cal_x,
                                            &ctlr->right_stick_cal_y,
                                            false);

Not sure if there's a way to detect this controller and use a different address for user calibration. Any ideas on how to find specs and how to detect this controller would be appreciated to provide a patch.

[DanielOgorchock]

Do you have a nintendo switch you could use to recalibrate the controller? If not, I'd try hardcoding joycon_check_for_cal_magic() to always return 1, making the controller use factory calibrations for both sticks. It sounds like there's bad user calibration data stored for the right stick, and the magic value is present, telling the driver to read the bad data.

[albfan]

@DanielOgorchock Do you think this is general issue? As this is a generic pro controller, my suspiction is that only cheap generic ones has this problems:

I have a pro controller and generic joycons to test (note squared + and - buttons, this are the cheapest ones):

Probably I can check with original ones and see if they behave different.

when the dkms (I'm on kernel 5.4 lts) is not active the axis are reported as 057e:2009 (pro controller), but as no driver deals with that, they are disconnected and reported as 0f0d:00c1 (horypad):

dmesg --follow
[14882.673977] usb 2-1.1: new full-speed USB device number 21 using ehci-pci
[14882.829410] usb 2-1.1: New USB device found, idVendor=057e, idProduct=2009, bcdDevice= 0.20
[14882.829417] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[14882.829421] usb 2-1.1: Product: Pro Controller
[14882.829425] usb 2-1.1: Manufacturer: Nintendo Co., Ltd.
[14882.829428] usb 2-1.1: SerialNumber: 000000000001
[14882.832869] input: Nintendo Co., Ltd. Pro Controller as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/0003:057E:2009.000E/input/input36
[14882.833320] hid-generic 0003:057E:2009.000E: input,hidraw0: USB HID v1.11 Joystick [Nintendo Co., Ltd. Pro Controller] on usb-0000:00:1d.0-1.1/input0

[14883.914066] usb 2-1.1: USB disconnect, device number 21

[14884.453983] usb 2-1.1: new full-speed USB device number 22 using ehci-pci
[14884.608810] usb 2-1.1: New USB device found, idVendor=0f0d, idProduct=00c1, bcdDevice= 5.72
[14884.608817] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[14884.608821] usb 2-1.1: Product: Switch Controller
[14884.608824] usb 2-1.1: Manufacturer:  
[14884.611064] input:   Switch Controller as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/0003:0F0D:00C1.000F/input/input37
[14884.611606] hid-generic 0003:0F0D:00C1.000F: input,hidraw0: USB HID v1.11 Gamepad [  Switch Controller] on usb-0000:00:1d.0-1.1/input0

from horipad the axis are reported as: ABS_ZZAN from 0-255 while on hid-nintendo they are reported as ABS_RX from -23764
to 32767. After manual calibration:

it works as expected.

Wonder if there's a way that dkms or kernel when it land on 5.10 attends an external config file, so you can calibrate joycons or procontroller for you personal use case. I can work a patch on that.

After that I want to fix the led (not available for joycons but available and not working for procontroller home) and add SL SR buttons (recognized on horipad, but not on hid-nintendo.

I review the @nadiaholmquist improvements and think that SL and SR are covered there so I can help reviewing those.

[albfan]

Oh, I just reread the comment. Have to check if I can recalibrate that info, right. Is there any tool to manually override that calibration?

[albfan]

nvm I found github.com/riking/joycon/prog4/jcdriver

Seems it has command to read write SPI flash data

[console]> [INFO] Connected to Switch Pro Controller 000000000001
Switch Pro Controller (000000000001): ▅⚡
000000000001: Got factory calibration and button colors
000000000001: SPI read returned [603d+25]
00000000  c8 85 61 e4 d7 7d 69 66  5c 4a 08 78 41 66 58 6a  |..a..}if\J.xAfXj|
00000010  b5 62 ff 32 32 32 ff ff  ff                       |.b.222...|
got subcommand reply packet: 58
00000000  ba 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00                                          |...|
Error: context deadline exceeded
Switch Pro Controller (000000000001): █⚡
[console]> read u1 0x603d 0x25

Have to do checks without my modified module and see how it behaves because looks like it gets right info from beginning.

• it is able to interact with led player lights, (wasn't able to switcch on home light in pro controller though)
• it maps correctly 'sl' 'sr' and looks like it do not mismatch btn_select and btn_start

I will put all that together and try to submit a patch if possible

[albfan]

I wasn't able to write SPI flash memory, nor try in a real nintendo switch so I just disabled all calibration.

I tried jcdriver but could only read memory.

About generic joycons, they are reported as pro controllers 057e:2008 but didn't report all the keys as a pro controller, so I think they can be detected due to its key capabilities (of course that's a tricky hack, to support a hacky fake hardware)

About bluetooth I wasn't able to sync pro controller or joycons, but using 8bitdo usb wireless adapter:

https://www.8bitdo.com/wireless-usb-adapter/

I can pair pro controller (but 8bitdo represents it as a x360 usb controller) and joycons are paired (only one of them each time) and they do not report any key press (seems something in the protocol refuses to send input keys to 8bitdo controller)

I know there's an automatic pairing on nintendo switch where each peer send its mac as a key, not sure if this driver can do something to fix bluetooth pairing.

I cannot figure out what to modify on bluez to get pro controller paired, any ideas?

[paxal]

Hi, Same here with an EasySMX SP5226 controller which does not work over bluetooth. I dig a bit and found that everything was working fine at Bluetooth HID level, but kernel did not recieve events at all. I looked at the HID descriptor which looked wrong, so I made a patch to force HID descriptor and it worked. It's kind of a ugly hack and I don't know how to make it cleaner: https://github.com/paxal/dkms-hid-nintendo/commit/b820e6e54b64f4b85e204c5a0d4b3c5a9d7e77a4

[albfan]

@paxal if you can open a PR I can provide review for it with my controllers. I guess that's the best way to refine it until it's ready to merge. I use the dkms module too

[paxal]

@albfan no need of a PR, you can add my repository to your remote or just clone mine and checkout the bad-hid-descriptor-patch branch. But I'm not sure our issues are related. My problem was that nothing was reported when pressing buttons or sticks :smile:

[albfan]

@paxal, I supposed your patch is to fix Bluetooth sync (I could only make it with my python script).

To move your patch from it works for you to merge here, you need a PR. Official dkms will include it eventually.

[aurel80]

Hi. First sorry for commenting on this quite old issue, but i encounter the exact same difficulty and was wondering if you had found a solution.

Recently, i purchased 8BitDO SN30 Pro+ controller, identifying itself as ProCon 057e:2009, which works great as a simple hid (bluetooth) gamepad. But when i use it in Switch mode, i cannot get it to work, especially the gyros/imu. I tried both the master branch of dkms module and the "bad descriptor" patched one, with the same result.

More precisely, i manage to get everything work but in only one specific case:

• as pointed out by Woazboat in this thread, i had to comment out the "joycon_leds_create" instruction ;
• the controller shall not have been paired previously: if it has been paired some time earlier, at the next connection, dmesg gives all the error messages mentioned in other posts; if i first "forget" the device in the bluetooth manager and pair it again, the driver loads smoothly, and /dev/js0 and /dev/js1 fire up, the first one for the joystick, the second one for the imu/gyros.

I'm not a professional developer, nor very at ease with hid and bluetooth. Thus, i'm stuck here. Something happens when pairing the device for the first time which does not next times the device is reconnected. I cannot figure out what on my own.

Also, two last strange (?) things:

• before module hid_nintendo loads, the device is recognized by hid-generic and dmesg tells that hidraw1 is created. When I check, /dev/hidraw1 is not visible (without hid_nintendo installed on the system, it is)
• i tried, through a userspace program, hidraw api and with hid_nintendo removed, to access the device. /dev/hidraw1 delivers the packets for buttons/axis but not for imu/gyros. When i try to write to the device and configure it to enable the imu (i tried to mimic the hid_nintendo code), it seems that the message is not sent. At least, no answer is returned and no new information, apart from buttons/axis status, is provided. It all seems like the gamepad was not ready to receive commands. Going back to the module source code, i could confirm the same behaviour. In function "joycon_ctlr_handle_event", no subcommand reply is received and thus, variable "ctlr->received_resp" is never set to true. This leads to a timeout in "joycon_hid_send_sync" function and to the "ret=-110 ugly error" like in previous posts.

Hope i'm not off topic and that these information can be of some help. And anyway, thank you for the great job you realise to bring Switch Controllers to Linux.

[cipitaua]

Hello,

I'm on ubuntu-devel, the following nintendo-pro (Nintendo licensed) controller

connects correctly via bluetooth with the hid-generic:

[ 1375.472523] hid-generic 0005:0F0D:00F6.0003: unknown main item tag 0x0
[ 1375.472751] input: Lic Pro Controller as /devices/virtual/misc/uhid/0005:0F0D:00F6.0003/input/input23
[ 1375.474035] hid-generic 0005:0F0D:00F6.0003: input,hidraw0: BLUETOOTH HID v0.01 Gamepad [Lic Pro Controller] on d8:f2:ca:b8:f6:95

and it works fine, joysticks and buttons fully usable (although the back leds keep blinking nonstop):

Now, to get also motion sensors data, I have installed dkms-hid-nintendo on kernel 3.11, and since the 0F0D:00F6 are different than the expected vendorID:productID (which for pro controller are 057e:2009) the hid-nintendo is not loaded. Thus I've changed the following lines of hid-ids.h

#define USB_VENDOR_ID_NINTENDO		0x057e
#define USB_DEVICE_ID_NINTENDO_PROCON	0x2009

into

#define USB_VENDOR_ID_NINTENDO		0x0f0d
#define USB_DEVICE_ID_NINTENDO_PROCON	0x00f6

in order to match those of my controller, and recompiled and reinstalled the hid-nintendo module. After connection now I get:

[307961.926641] nintendo 0005:0F0D:00F6.0015: unknown main item tag 0x0
[307961.926928] nintendo 0005:0F0D:00F6.0015: hidraw0: BLUETOOTH HID v80.01 Gamepad [Lic Pro Controller] on d8:f2:ca:b8:f6:95
[307964.022147] nintendo 0005:0F0D:00F6.0015: using factory cal for left stick
[307964.045275] nintendo 0005:0F0D:00F6.0015: using factory cal for right stick
[307964.120600] nintendo 0005:0F0D:00F6.0015: using factory cal for IMU
[307964.255538] nintendo 0005:0F0D:00F6.0015: controller MAC = 30:31:7D:44:58:60
[307964.289986] input: Nintendo Switch Pro Controller as /devices/virtual/misc/uhid/0005:0F0D:00F6.0015/input/input48
[307964.295560] input: Nintendo Switch Pro Controller IMU as /devices/virtual/misc/uhid/0005:0F0D:00F6.0015/input/input49

thus the hid-nintendo now gets triggered, and I can see the IMU motion working:

However, joysticks and buttons are no more usable.

Should it be possible to get motion sensors data in addition to joysticks and buttons?

[cipitaua]

By fumbling with the code I've managed to get a fully functional driver for the HORI CO.,LTD. HORI Wireless Switch Pad [Lic Pro Controller].

I've tested it with joycond-cemuhook and cemu (the latter under wine), it works perfectly.

hori.zip

It is presently a modified hid-nintendo in which I've changed vendor and device IDs (0F0D:00F6) and disabled all the home_led related parts (being absent), and auto calibration.

Please take a look and let me know if it works for you. In such case, it should be easy to generalize the original hid-nintendo in order to add HORI as special case.

[albfan]

@cipitaua even if not merged this seems to be a common device so if you can just open a PR to show your changes it can help others or finally get merged if vendor and id is detected

[cipitaua]

@albfan you can see my changes from the hori.zip attached in my previous post!

[albfan]

An issue is to collaborate, review, and get a solution.

The easier you show the higher chances to get a global solution maintained.

Personally I'm already reviewing the zip

[cipitaua]

@albfan OK, my idea was that someone else test the code and suggest how to merge it. I don't want to make a PR without some agreement ;)

[shadowofdarkness]

I know this is not part of the issue but I was very curious and tried searching elsewhere but could not find any answers. So cipitaua could you please tell me what software you are using in that screenshot? I think it looks pretty good and would like to try it out myself.

[cipitaua]

@shadowofdarkness it is simply the systemsetting of kde plasma-desktop. However, for the sake of truly testing the motion I'd recommend to use the DSU Pad Test application (it works well under wine, screenshot here) in combination with joycond-cemuhook (or in alternative evdevhook, also fine).