xpad icon indicating copy to clipboard operation
xpad copied to clipboard

Add Support for Shanwan Controller

Open AdityaHebballe opened this issue 3 months ago • 1 comments

My controller has 2 modes: xinput and dinput. On linux it presents the product and vendor ID for xinput mode and then it fails to fallback to dinput mode.

└─> sudo /bin/grep --line-buffered -Po '(?<=0 0 18 = .{18}).{8}' /sys/kernel/debug/usb/usbmon/1u | /bin/sed -E 's/([0-9a-f]{2})([0-9a-f]{2})([0-9a-f]{2})([0-9a-f]{2})/\2\1:\4\3/'
2563:0575
2563:0575
20bc:5001
20bc:5001

In dmesg I get the following error:

[ 4351.786243] usb 1-2: new full-speed USB device number 104 using xhci_hcd
[ 4352.197248] usb 1-2: unable to read config index 0 descriptor/start: -71
[ 4352.197256] usb 1-2: can't read configurations, error -71
[ 4352.786240] usb 1-2: new full-speed USB device number 105 using xhci_hcd
[ 4353.069059] usb 1-2: New USB device found, idVendor=20bc, idProduct=5001, bcdDevice= 1.24
[ 4353.069067] usb 1-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0

This is the controller for reference

In fallback mode it is recognized as so: Bus 001 Device 105: ID 20bc:5001 ShenZhen ShanWan Technology Co., Ltd. Gamepad

I've tried in both wired and dongle mode.

Please help me figure out how to patch the driver.

AdityaHebballe avatar Sep 12 '25 19:09 AdityaHebballe

FWIW, I have the same controller, and I am on a Fedora 42 machine (kernel 6.16.12).

  1. With no additional changes (stock F42, with stock kernel modules):

The device initially reports itself with VID 0x2563 and PID 0x028e in response to the Get Descriptor Request Device USB packet. However, the subsequent Get Descriptor Request Configuration USB packet triggers a protocol error (-EPROTO, -71) response. This request/response sequence occurs two more times, after which the device disconnects and reconnects itself automatically. This time it reports new VID and PID values:

Wired: 0x05ac, 0x033e Wireless: 0x20bc, 0x5001

The 3rd LED light on the controller is active, which according to the user manual means it is in Android mode. The hid_generic driver is used, and there is no rumble support.

  1. With modified kernel parameters:

Using the kernel parameters: usbcore.old_scheme_first=1, the device connects and initially reports VID/PID as mentioned above, but then re-enumerates itself as:

Bus 005 Device 021: ID 057e:2009 Nintendo Co., Ltd Switch Pro Controller

At this point, only the 1st LED light on the controller is active. The hid_nintendo module gets loaded, and rumble works, however the X&Y and A&B buttons are swapped.

If I further blacklist the hid_nintendo module, the device re-enumerates itself as

Bus 005 Device 023: ID 0d22:0c31 HORI CO.,LTD. Gamepad

This uses the hid_generic driver and there is no rumble support. As above, only the 1st LED light on the controller is active. Both of these behaviors are undocumented, and I couldn't find them on the manufacturer's website or in the user manual. Modes cannot be switched through holding the HOME button (as mentioned in the manual), in any scenario.


I tried patching the xpad driver with these new hardware ID's but to no avail. On Windows, the Get Descriptor Request Configuration USB packet response does not fail, and the controller gets correctly identified as a Xbox 360 controller (this could be worth investigating).

NightShade256 avatar Oct 21 '25 19:10 NightShade256