Gulikit KingKong2 unable to properly sync

[preland]

(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.]

[nlflint]

how would I build the kernel module in this repo and apply it?

There's 2 ways I know how to do this:

1. Compile a custom kernel: You get an entire kernel source, from here, or a vanilla version with nintendo patches applied. Compile it and include it in your boot loader. I've done this with a patch from here and it worked: 3rd Party Joycon Compatibility #40 (comment)

2. Compile just the nintendo driver against your kernel as an "out-of-tree" DKMS module and add it to your system. There's automation available to automatically rebuilld the module when your distro updates it's kernel. Pretty cool. I've never done this before, but you should be able to find more info by searching how to compile and load out-of-tree dkms modules. There's an archived project here, but you might be able to start from here and make your own: https://github.com/nicman23/dkms-hid-nintendo/blob/master/dkms.conf

This commenter describes their process for loading the nintendo driver as a DKMS module. Maybe another good place to research how to do it: #36 (comment)