Flydigi Vader 5S (37d7:2801) - xone-wired probe fails with error -71

[Litzner]

Device:
Flydigi Vader 5S (wired-only, officially Xbox-licensed controller) USB ID: idVendor=37d7, idProduct=2801, bcdDevice=1.01 Kernel: 7.0.10-2-cachyos xone version: 0.5.8-2 (DKMS) Distribution: CachyOS (Arch-based)

Interface details (both interfaces identical):
bInterfaceClass: ff (Vendor Specific)
bInterfaceSubClass: 47
bInterfaceProtocol: d0

Problem:
The Flydigi Vader 5S is not recognized by xone. After manually injecting the device ID via new_id, xone-wired probes the device but immediately fails:
xone-wired 7-1:1.0: probe with driver xone-wired failed with error -71
usb 7-1: USB disconnect, device number 19

The controller then enters a disconnect/reconnect boot loop. Testing with xpad also fails, a brief input node is created but the controller resets with:
input input56: unable to disable audio interface: -71

Both failures are at the GIP handshake/init stage. The interface class ff/47/d0 correctly identifies this as a GIP device, so the issue is the init sequence the controller expects differs from what xone currently sends.

Additional notes:
The Flydigi Apex 5 (37d7:2501) was added to mainline xpad in kernel 6.17, the Vader 5S uses a different product ID and appears to need a different GIP init sequence

The Vader 5S is a new (2025/2026) officially Xbox-licensed wired controller, it is not the same as the Vader 5 Pro

flydigi_vader5s_37d7_2801_windows_init.zip

I will attach a Wireshark/USBPcap capture of the device initializing on Windows to help identify the correct GIP handshake sequence.

[ykpmusicstudio]

In case it helps (and still works, I hope), here are my lua dissectors for GIP & GIP over MT76 that helps filtering on gip_usb or gip_usb_mt76.

gip_lua.tar.gz

[ykpmusicstudio]

Oh, btw, other gamepad had issue with the stale auth/handshake phase. One culprit may be sequence numbers. I do not garantee that you issue is the same but some changes were made to debug specific gamepad behaviours.

If you do not mind trying out #200 which tries a fix and gives full packet traces that you can compare with windows capture to find differences.

I'll be interrested to see the logs of another stuck handshake.

edit: you may need to add your device ID manually in the PR code if missing from the probe table.