DanielOgorchock / linux

Other
48 stars 7 forks source link

3rd Party Joycon Compatibility #40

Open macromorgan opened 2 years ago

macromorgan commented 2 years ago

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).

grego9 commented 1 year ago

I've tried some cheap joycons with no luck either. In my case, I can pair them as individual controllers, but they start to rumble non-stop.

arieleoar commented 1 year ago

Same here, system recognizes JoyCons as Pro controllers and S buttons doesn't works at all, even joycond doesn't work as it cannot pair correctly the devices. I'm using dkms module from nicman23 because if i use builtin hid-nintendo module from the kernel provided in ubuntu 22.10 it makes the system crash awfully.

Do you know where exactly we should file a bug for this as it is now directly provided in different linux distros?

dietolive-tw commented 7 months ago

I have a 3rd Party pro-controller, after apply following patch, it can work, and it was hacked from SDL

--- ../f/linux-6.7/drivers/hid/hid-nintendo.c   2024-01-08 04:18:38.000000000 +0800
+++ drivers/hid/hid-nintendo.c  2024-01-23 08:29:15.453448548 +0800
@@ -2116,12 +2116,15 @@
    int ret;
    int i;
    int j;
-   struct joycon_subcmd_request req = { 0 };
+   struct joycon_subcmd_request *req;
    struct joycon_input_report *report;
+   u8 buffer[sizeof(*req) + 38] = { 0 };

-   req.subcmd_id = JC_SUBCMD_REQ_DEV_INFO;
+   req = (struct joycon_subcmd_request *)buffer;
+
+   req->subcmd_id = JC_SUBCMD_REQ_DEV_INFO;
    mutex_lock(&ctlr->output_mutex);
-   ret = joycon_send_subcmd(ctlr, &req, 0, HZ);
+   ret = joycon_send_subcmd(ctlr, req, 38, HZ);
    mutex_unlock(&ctlr->output_mutex);
    if (ret) {
        hid_err(ctlr->hdev, "Failed to get joycon info; ret=%d\n", ret);
@@ -2318,8 +2321,27 @@

    ctlr->hdev = hdev;
    ctlr->ctlr_state = JOYCON_CTLR_STATE_INIT;
-   ctlr->rumble_queue_head = 0;
+   ctlr->rumble_queue_head = JC_RUMBLE_QUEUE_SIZE - 1;
    ctlr->rumble_queue_tail = 0;
+
+#if 1
+   /* (k) */
+   {
+       int i;
+
+       for (i=0; i<JC_RUMBLE_QUEUE_SIZE; i++) {
+           ctlr->rumble_data[i][0] = 0x00;
+           ctlr->rumble_data[i][1] = 0x01;
+           ctlr->rumble_data[i][2] = 0x40;
+           ctlr->rumble_data[i][3] = 0x40;
+           ctlr->rumble_data[i][4] = 0x00;
+           ctlr->rumble_data[i][5] = 0x01;
+           ctlr->rumble_data[i][6] = 0x40;
+           ctlr->rumble_data[i][7] = 0x40;
+       }
+   }
+#endif
+
    hid_set_drvdata(hdev, ctlr);
    mutex_init(&ctlr->output_mutex);
    init_waitqueue_head(&ctlr->wait);
@@ -2361,6 +2383,10 @@

    hid_device_io_start(hdev);

+   /* (k)  wake up joystick */
+   ret = joycon_read_info(ctlr);
+
+
    ret = joycon_init(hdev);
    if (ret) {
        hid_err(hdev, "Failed to initialize controller; ret=%d\n", ret);
cipitaua commented 7 months ago

I have a 3rd Party pro-controller, after apply following patch, it can work, and it was hacked from SDL

could you post a photo of your controller that works with the above patch? thank you

dietolive-tw commented 7 months ago

IMG_4664 IMG_4663 the dmesg:

[114874.234521] nintendo 0005:057E:2009.0010: unknown main item tag 0x0
[114874.235867] nintendo 0005:057E:2009.0010: hidraw4: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on 80:86:f2:ae:6f:a9
[114874.268138] nintendo 0005:057E:2009.0010: controller MAC = 98:B6:E9:4C:41:D2
[114876.356201] nintendo 0005:057E:2009.0010: using user cal for left stick
[114876.368204] nintendo 0005:057E:2009.0010: using user cal for right stick
[114876.380193] nintendo 0005:057E:2009.0010: Failed to read left stick cal, using defaults; e=-22
[114876.400201] nintendo 0005:057E:2009.0010: Failed to read right stick cal, using defaults; e=-22
[114876.420200] nintendo 0005:057E:2009.0010: using factory cal for IMU
[114876.506148] nintendo 0005:057E:2009.0010: controller MAC = 98:B6:E9:4C:41:D2
[114876.530649] input: Nintendo Switch Pro Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-14/1-14:1.0/bluetooth/hci0/hci0:256/0005:057E:2009.0010/input/input42
[114876.531255] input: Nintendo Switch Pro Controller IMU as /devices/pci0000:00/0000:00:14.0/usb1/1-14/1-14:1.0/bluetooth/hci0/hci0:256/0005:057E:2009.0010/input/input43
[114879.070097] nintendo 0005:057E:2009.0010: compensating for 6 dropped IMU reports
[114879.070102] nintendo 0005:057E:2009.0010: delta=31 avg_delta=4
[114879.096159] nintendo 0005:057E:2009.0010: compensating for 5 dropped IMU reports
[114879.096170] nintendo 0005:057E:2009.0010: delta=26 avg_delta=4
[114879.458096] nintendo 0005:057E:2009.0010: joycon_enforce_subcmd_rate: exceeded max attempts
[114882.236207] nintendo 0005:057E:2009.0010: joycon_enforce_subcmd_rate: exceeded max attempts
[114884.075183] nintendo 0005:057E:2009.0010: compensating for 4 dropped IMU reports
[114884.075194] nintendo 0005:057E:2009.0010: delta=30 avg_delta=5
[114885.068187] nintendo 0005:057E:2009.0010: joycon_enforce_subcmd_rate: exceeded max attempts
cipitaua commented 7 months ago

thank you. It's the shittiest controller I have ever seen 😄

nlflint commented 4 months ago

I have a 3rd Party pro-controller, after apply following patch, it can work, and it was hacked from SDL

<patch omitted>

I have a King Kong 2 controller (in nintendo switch mode) with the same ret=-110 problem in kernel (6.8.2). I tried your patch on kernel 6.8.2 but the first part of the patch didn't apply cleanly (part 2 and 3 did). I was able to patch part1 by hand though. I compiled one version without the mutex (it's gone in 6.8.2), then ran another compilation that brought the mutex back.

Both versions (mutex or not) seem to behave the same, but the controller still doesn't work. It got rid of the return error in dmesg when paired, but the controller still isn't recognized by apps like Steam, jstest, or yuzu.

dietolive-tw commented 4 months ago

the patch of kernel 6.8.x will be like this, hope it can help.

--- b/linux-6.8.1/drivers/hid/hid-nintendo.c    2024-03-16 02:19:29.000000000 +0800
+++ a/linux-6.8.1/drivers/hid/hid-nintendo.c    2024-03-19 11:00:51.493562603 +0800
@@ -2469,11 +2469,14 @@
    int ret;
    int i;
    int j;
-   struct joycon_subcmd_request req = { 0 };
+   struct joycon_subcmd_request *req;
    struct joycon_input_report *report;
+   u8 buffer[sizeof(*req) + 38] = { 0 };

-   req.subcmd_id = JC_SUBCMD_REQ_DEV_INFO;
-   ret = joycon_send_subcmd(ctlr, &req, 0, HZ);
+   req = (struct joycon_subcmd_request *)buffer;
+
+   req->subcmd_id = JC_SUBCMD_REQ_DEV_INFO;
+   ret = joycon_send_subcmd(ctlr, req, 38, HZ);
    if (ret) {
        hid_err(ctlr->hdev, "Failed to get joycon info; ret=%d\n", ret);
        return ret;
@@ -2691,8 +2694,27 @@

    ctlr->hdev = hdev;
    ctlr->ctlr_state = JOYCON_CTLR_STATE_INIT;
-   ctlr->rumble_queue_head = 0;
+   ctlr->rumble_queue_head = JC_RUMBLE_QUEUE_SIZE - 1;
    ctlr->rumble_queue_tail = 0;
+
+#if 1
+   /* (k) */
+   {
+       int i;
+
+       for (i=0; i<JC_RUMBLE_QUEUE_SIZE; i++) {
+           ctlr->rumble_data[i][0] = 0x00;
+           ctlr->rumble_data[i][1] = 0x01;
+           ctlr->rumble_data[i][2] = 0x40;
+           ctlr->rumble_data[i][3] = 0x40;
+           ctlr->rumble_data[i][4] = 0x00;
+           ctlr->rumble_data[i][5] = 0x01;
+           ctlr->rumble_data[i][6] = 0x40;
+           ctlr->rumble_data[i][7] = 0x40;
+       }
+   }
+#endif
+
    hid_set_drvdata(hdev, ctlr);
    mutex_init(&ctlr->output_mutex);
    init_waitqueue_head(&ctlr->wait);
nlflint commented 4 months ago

the patch of kernel 6.8.x will be like this, hope it can help.

Excellent, with that patch, my Gulikit King Kong 2 (in switch mode, via bluetooth) is working now. Steam and Yuzu detect it and the controls are responding. The tester JSTest-gtk still doesn't detect it, but it doesn't matter.

emiliopedrollo commented 1 month ago

I also have a Gulikit KingKong2 but I'm not being able to properly connect it.

I'm trying to build a dkms module by extracting hid-nintendo.c from the kernal 6.8 source and pasting it on a clone of nicman32 repository, then apllying the patch from https://github.com/DanielOgorchock/linux/issues/40#issuecomment-2029009734.

I'm not sure if I should blacklist hid_nintendo from modprob or even if I can do it and still use the dkms version. Or maybe the problem isn't related to that at all. Or even if the whole copy into a dkms thing is a thing at all.

dsmeg
[667258.618222] nintendo 0005:057E:2009.0033: unknown main item tag 0x0
[667258.619155] nintendo 0005:057E:2009.0033: hidraw12: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on 28:c2:dd:02:53:f9
[667262.717721] nintendo 0005:057E:2009.0033: failed reading SPI flash; ret=-110
[667262.717735] nintendo 0005:057E:2009.0033: using factory cal for left stick
[667264.765772] nintendo 0005:057E:2009.0033: failed reading SPI flash; ret=-110
[667264.765785] nintendo 0005:057E:2009.0033: using factory cal for right stick
[667266.813778] nintendo 0005:057E:2009.0033: failed reading SPI flash; ret=-110
[667266.813792] nintendo 0005:057E:2009.0033: Failed to read left stick cal, using dflts; e=-110
[667268.861859] nintendo 0005:057E:2009.0033: failed reading SPI flash; ret=-110
[667268.861873] nintendo 0005:057E:2009.0033: Failed to read right stick cal, using dflts; e=-110
[667270.909871] nintendo 0005:057E:2009.0033: failed reading SPI flash; ret=-110
[667270.909889] nintendo 0005:057E:2009.0033: using factory cal for IMU
[667272.957946] nintendo 0005:057E:2009.0033: failed reading SPI flash; ret=-110
[667272.957961] nintendo 0005:057E:2009.0033: Failed to read IMU cal, using defaults; ret=-110
[667272.957965] nintendo 0005:057E:2009.0033: Unable to read IMU calibration data
[667272.957968] ------------[ cut here ]------------
[667272.957971] UBSAN: array-index-out-of-bounds in /var/lib/dkms/nintendo/3.2/build/src/hid-nintendo.c:960:11
[667272.957977] index 0 is out of range for type 'u8 [*]'
[667272.957982] CPU: 3 PID: 710658 Comm: (udev-worker) Tainted: P           OE      6.8.0-36-generic #36-Ubuntu
[667272.957988] Hardware name: ASUS All Series/X99-DELUXE, BIOS 3701 03/30/2017
[667272.957991] Call Trace:
[667272.957995]  
[667272.958000]  dump_stack_lvl+0x48/0x70
[667272.958017]  dump_stack+0x10/0x20
[667272.958024]  __ubsan_handle_out_of_bounds+0xc6/0x110
[667272.958034]  nintendo_hid_probe+0x50c/0x1d10 [hid_nintendo]
[667272.958050]  ? kernfs_activate+0x90/0xc0
[667272.958057]  ? kmalloc_trace+0x139/0x350
[667272.958070]  hid_device_probe+0x130/0x1b0 [hid]
[667272.958099]  really_probe+0x1c7/0x410
[667272.958108]  __driver_probe_device+0x8c/0x180
[667272.958115]  driver_probe_device+0x24/0xd0
[667272.958121]  __device_attach_driver+0xcd/0x170
[667272.958128]  ? __pfx___device_attach_driver+0x10/0x10
[667272.958134]  bus_for_each_drv+0x97/0xf0
[667272.958140]  __device_attach+0xb6/0x1d0
[667272.958146]  ? __pfx___hid_bus_reprobe_drivers+0x10/0x10 [hid]
[667272.958168]  device_attach+0x10/0x20
[667272.958174]  bus_rescan_devices_helper+0x52/0xc0
[667272.958179]  device_reprobe+0x23/0x40
[667272.958184]  __hid_bus_reprobe_drivers+0x6c/0x70 [hid]
[667272.958204]  bus_for_each_dev+0x8d/0xf0
[667272.958210]  ? __pfx___hid_bus_driver_added+0x10/0x10 [hid]
[667272.958230]  __hid_bus_driver_added+0x2c/0x50 [hid]
[667272.958250]  bus_for_each_drv+0x97/0xf0
[667272.958256]  __hid_register_driver+0x80/0xa0 [hid]
[667272.958277]  ? __pfx_nintendo_hid_driver_init+0x10/0x10 [hid_nintendo]
[667272.958290]  nintendo_hid_driver_init+0x23/0xff0 [hid_nintendo]
[667272.958303]  do_one_initcall+0x5e/0x340
[667272.958315]  do_init_module+0xc0/0x2c0
[667272.958324]  load_module+0xba1/0xcf0
[667272.958332]  init_module_from_file+0x96/0x100
[667272.958337]  ? init_module_from_file+0x96/0x100
[667272.958344]  idempotent_init_module+0x11c/0x2b0
[667272.958350]  __x64_sys_finit_module+0x64/0xd0
[667272.958355]  x64_sys_call+0x1d6e/0x25c0
[667272.958360]  do_syscall_64+0x7f/0x180
[667272.958369]  ? do_syscall_64+0x8c/0x180
[667272.958376]  ? do_syscall_64+0x8c/0x180
[667272.958383]  ? do_syscall_64+0x8c/0x180
[667272.958390]  ? do_syscall_64+0x8c/0x180
[667272.958396]  ? irqentry_exit+0x43/0x50
[667272.958401]  ? exc_page_fault+0x94/0x1b0
[667272.958406]  entry_SYSCALL_64_after_hwframe+0x78/0x80
[667272.958413] RIP: 0033:0x799dbe92725d
[667272.958448] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8b bb 0d 00 f7 d8 64 89 01 48
[667272.958453] RSP: 002b:00007ffd61ea1778 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[667272.958459] RAX: ffffffffffffffda RBX: 000055fd53539c70 RCX: 0000799dbe92725d
[667272.958463] RDX: 0000000000000004 RSI: 0000799dbea6e07d RDI: 0000000000000012
[667272.958466] RBP: 00007ffd61ea1830 R08: 0000000000000040 R09: 00007ffd61ea17c0
[667272.958469] R10: 0000799dbea03b20 R11: 0000000000000246 R12: 0000799dbea6e07d
[667272.958473] R13: 0000000000020000 R14: 000055fd5356fc50 R15: 000055fd535db5f0
[667272.958478]  
[667272.958481] ---[ end trace ]---
[667275.006974] nintendo 0005:057E:2009.0033: Failed to set report mode; ret=-110
[667275.007239] nintendo 0005:057E:2009.0033: probe - fail = -110
[667275.007277] nintendo: probe of 0005:057E:2009.0033 failed with error -110
[667463.282030] nintendo 0005:057E:2009.0034: unknown main item tag 0x0
cipitaua commented 1 month ago

I'm not sure if I should blacklist hid_nintendo from modprob or even if I can do it and still use the dkms version. Or maybe the problem isn't related to that at all. Or even if the whole copy into a dkms thing is a thing at all.

it should not be necessary if you keep the same name of the module, it will be considered an update and replace the official one.