GameSir K1 Kaleid (3537:1082) - HID device claimed by hid-generic, no FF/rumble support

[abdulrahman-a-dev]

Controller: GameSir K1 Kaleid
VID:PID: 3537:1082
OS: Nobara Linux (Fedora-based), kernel 7.0.9-200.nobara.fc43.x86_64

Problem:
The controller enumerates as a USB HID device and is claimed by hid-generic.
No force feedback support. fftest shows 0 simultaneous effects and all uploads
fail with "Function not implemented".

xpad does not load as a HID driver on this system (not present in
/sys/bus/hid/drivers/). xpad_noone is USB-layer only and cannot bind to HID
devices.

Request:
Add 3537:1082 to xpad's HID device table to enable FF/rumble support.

The T4 Kaleid (3537:1004) is already listed — the K1 uses the same vendor
but a different PID.

[TeknoRakun]

TL;DR
hid_generic claims this device, it falls to generic HID mode. Generic HID PID 1082, "cold boot" PID 1096 and working PID 1067. Race conditions brakes that behaviour so other modules (xpad or xone) can claim the device and work as intended with force feedback, recognized as XBOX controller.

I had same issue recently too, then I figured out a janky way. At first, I added vendor and product ID to xpad.c but somehow hid_generic claimed the device, it is I think because of the fact GameSir uses 2 pipelines to communicate with their software and initialize the device as a XBOX controller. When plugged first it gets 3537:1096 ids, that is where hid_generic claims and fails. Then device goes to fallback, generic HID and it is the 3537:1082. On Windows side when driver claims the device it gets 3537:1067. I tried a lot of things to stop any other driver than my patched xpad to claim device but no succes, then I plugged my headphones to charge via USB cable and I gave the driver one last try, it worked! It attached as 3537:1067 and all functions working. Then I looked at the dmesg -w output, my headphone causes a race condition where hid_generic tries to claim the headphone as a HID device. While hid_generic goes nuts trying that, both patched xpad and xone_wired can claim the device to go through GIP handshake. I will try that with other devices too but so far it is the first time I saw something like that. My best guess is my setup does not have a EHCI controller, even USB 2.0 ports routed through XHCI so hdi_generic somehow able to claim whatever plugged in even with udev rules or manually unbinding the module. I never had that kind of experience with offical Microsoft XBOX ONE controller though.

I will report that issue to xone too, I hope someone knows actually what's happening solve this problem.

Setup:
Arch Linux 7.1.3-zen1-1-zen kernel
KDE Plasma 6.7.2-1 using Wayland

Kaleid Firmware version: 1.26

Everything is listed down there not worked for me!
udev rule I tried:
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="3537", RUN+="/bin/sh -c 'echo 3537 %E{PRODUCT} | cut -d/ -f2-3 > /sys/bus/usb/drivers/xpad/new_id'"

cmdline strings I tried:
usbhid.quirks=0x3537:0x1067:0x04,0x3537:0x1096:0x04,0x3537:0x1082:0x04
usbcore.quirks=3537:1096:g
usbcore.quirks=3537:1096:bk
usbcore.quirks=3537:1096:bk,3537:1067:bk,3537:1082:bk

edit:wrong name xpad->xone