xpad
xpad copied to clipboard
paroj
Some controllers that mimic the Xbox 360 Controller are not initialized correctly
I have a fake Xbox 360 controller, specifically a Fantech GP11 Shooter, it happens that this type of controllers have problems to work on Linux because they are first recognized by usbhid and then disconnected and reconnected as controllers of xbox 360, to then not generate any key event.
In this case my problem is identical to this: Linux gamepad - no input events
And this is very similar: #118
Using VirtualBox, Wireshark and usbmon I analyzed the traffic between the device and the linux driver looking for the initialization codes, after finding them I wrote the following script: fixcontroller.py
I do not provide more data, like the output of dmesg, because they are the same as the first link I left.
But if necessary I can provide more information or try any solution they propose, in advance I apologize if something is not well understood, since this was translated from Spanish.
I just got a new gamepad: Trust GXT 540 Yula. It has a button to switch between D-input and X-input modes: dinput works OOTB with no issues, albeit it has support for less features and some games don't accept it. xinput refuses to work, the device is recognized by the OS but no buttons or events are sensed. I asked why that is and someone pointed me to this issue.
I can confirm the problem reported here is the cause: The python script provided as a workaround fixes the problem and gets the device fully working in this input mode. Of course it must be ran each time after the controller is plugged in or the machine is restarted, which is very annoying and problematic to do (especially since it wants root access).
This is a concerning problem: Any information on when it might be resolved? Feel free to ask me for more data if it helps fix this... my OS is Manjaro KDE for the record. In the meantime is there an easier workaround to that python script, such as a bash script that does the same thing which would be easier to automate, or some OS setting we can change to fix the bad detection?
Some basic info. First the device is listed as Bus 005 Device 024: ID 045e:028e Microsoft Corp. Xbox360 Controller by the lsusb command; It's not a real Xbox controller and IMO it was a bad design choice to label it as such.
The usb-devices command lists the controller as follows:
T: Bus=05 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 26 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1
P: Vendor=045e ProdID=028e Rev=01.10
S: Manufacturer=SHANWAN
S: Product=Controller
C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=5d Prot=01 Driver=xpad
Lastly for now here's the dmesg log piece after plugging in the device:
1336a1337,1351
> [ 3317.060917] usb 5-2.1: new full-speed USB device number 6 using xhci_hcd
> [ 3317.184666] usb 5-2.1: New USB device found, idVendor=2563, idProduct=0575, bcdDevice= 2.00
> [ 3317.184669] usb 5-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [ 3317.184671] usb 5-2.1: Product: PS3/PC Gamepad
> [ 3317.184672] usb 5-2.1: Manufacturer: SHANWAN
> [ 3317.286799] input: SHANWAN PS3/PC Gamepad as /devices/pci0000:00/0000:00:08.1/0000:0c:00.3/usb5/5-2/5-2.1/5-2.1:1.0/0003:2563:0575.0004/input/input22
> [ 3317.286852] hid-generic 0003:2563:0575.0004: input,hidraw3: USB HID v1.10 Gamepad [SHANWAN PS3/PC Gamepad] on usb-0000:0c:00.3-2.1/input0
> [ 3317.861781] usb 5-2.1: USB disconnect, device number 6
> [ 3318.177585] usb 5-2.1: new full-speed USB device number 7 using xhci_hcd
> [ 3318.303668] usb 5-2.1: New USB device found, idVendor=045e, idProduct=028e, bcdDevice= 1.10
> [ 3318.303672] usb 5-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [ 3318.303673] usb 5-2.1: Product: Controller
> [ 3318.303674] usb 5-2.1: Manufacturer: SHANWAN
> [ 3318.922012] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:08.1/0000:0c:00.3/usb5/5-2/5-2.1/5-2.1:1.0/input/input23
> [ 3318.922074] usbcore: registered new interface driver xpad
@dnmodder Someone on Reddit suggested this. Unfortunately I never had to manually mess with udev before. Could anyone explain what needs to be edited and where and how? I can tell this obviously involves messing with root / system stuff and I'm always weary not to risk breaking something.
If that's easier, a script or command written in bash (no python) would also be helpful until this is resolved. I tried stuff like echo 1 > /dev/bus/usb/005/011 as a test to see what that does, but it just throws an invalid argument error and that's it.
@MirceaKitsune Write the following to a text file:
ACTION=="add", ATTRS{idProduct}=="028e", ATTRS{idVendor}=="045e", DRIVERS=="usb", RUN+="/path/to/script.py"
changing the script path, then save this file as 99-fixcontroller.rules (I chose that name at random) in /etc/udev/rules.d/99-fixcontroller.rules, then run the following command in a terminal:
sudo udevadm control --reload
That should be enough.
Guess that script is the only way then. Mainstreamed it to a more permanent configuration. I don't mind executing it manually when plugging in the controller for now, but will keep that solution in mind too for ease. Thanks for all the help!
Also what happened to PR #120 if I may ask? I took a look and everyone says it's supposed to fix this issue, however it just dropped dead two years ago with no updates since. Was it just forgotten or is there a reason why it's waiting for so long?
@MirceaKitsune It is functional, since it does basically the same as the script but directly from the driver, but it is not written in the most adequate way, but it was the best the author of the PR could do, and I do not know how to program in C ++.
Hmmm. Does it break anything in its current form? I support clean code, but over letting such an issue persist I'd take even an official workaround that's less ideal. Hope a solution in some form is found and accepted soon.
should be fixed with https://github.com/paroj/xpad/commit/2bfb0e171832b5035a9370300d7fdf4c57eb9497
Thank you very much, I appreciate it! Anyone know which kernel version should have the patch? Once it's on my system I'll give it a go and hopefully everything will work great.
Anyone know which kernel version should have the patch?
this is not scheduled for upstream yet. You can use it with your current kernel as described here, though: https://github.com/paroj/xpad#installing
moved the fix to a separate branch: https://github.com/paroj/xpad/tree/fantech
I got reports that the change breaks other controllers in #171. As the controllers identifies as 0x045e:0x028e i.e. "vanilla Xbox360 Controller", there is no way to create a whitelist right now.
Perhaps we can whitelist it using iManufacturer SHANWAN. I have attached the lsusb output of my controller. lsusb.txt
@paroj Thank you for this fix and your continued awesome efforts! I had just started to reverse engineer the commands that pyusb issued to the kernel to build it and was VERY happy to stumble across your patch where you had done a far better job than I would have anyway!
Since it's been communicated that this new code is controller specific and breaks others, in my own build I've modified your new patch and added a new quirk to your "mapping" property that I then assign to the vendor+product inside the definition of xpad_device. Then instead of checking xpad->xtype to determine if the new function should be called I check xpad->mapping.
This solution is working very well for me in my testing for my gamepad idVendor=2563, idProduct=0575.
- UPDATE - Upon further testing I discovered that while the patch works for enabling the controller, the mappings/quirks are not passed through to the new xbox device - I need the triggers to be mapped as buttons.
The kernel first correctly creates the input for idVendor=2563, idProduct=0575 and after debugging the driver init sequence I can confirm this initial device properly maps the triggers as buttons. However, shortly after this happens the kernel then replaces this input devices with a new one with idVendor=045e, idProduct=028e. All input events are detected for this new device, which doesn't pick up the original mappings for the actual vendor/product, so my triggers are mapped as axis.
lsusb does not show my actual vendor/product anymore, it shows the new device instead.
Bus 001 Device 003: ID 045e:028e Microsoft Corp. Xbox360 Controller
Here's my output after adding the product/vendor to the device table with the proper mappings:
[ 4.879123] usb 1-1: new full-speed USB device number 2 using dwc2
[ 5.154783] usb 1-1: New USB device found, idVendor=2563, idProduct=0575
[ 5.155412] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 5.156049] usb 1-1: Product: PS3/PC Gamepad
[ 5.156426] usb 1-1: Manufacturer: SHANWAN
[ 5.160432] input: Roshambo Gamepad as /devices/platform/ff580000.usb/usb1/1-1/1-1:1.0/input/input3
[ 5.305146] usb 1-1: USB disconnect, device number 2
[ 6.172070] usb 1-1: new full-speed USB device number 3 using dwc2
[ 6.447874] usb 1-1: New USB device found, idVendor=045e, idProduct=028e
[ 6.448495] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 6.449132] usb 1-1: Product: Controller
[ 6.449479] usb 1-1: Manufacturer: SHANWAN
[ 6.452609] input: Microsoft X-Box 360 pad as /devices/platform/ff580000.usb/usb1/1-1/1-1:1.0/input/input5
Any thoughts on why that new device is being picked up with a different vendor/product? When I map it out, It appears to even being given an entirely different guid too confused face
For now, I've added code to the driver that inspects the manufacturer, and if it's a shanwan device it forces the triggers to buttons. Not ideal, but a hacky workaround until this gets figured out.
Another note is that suspend/resume do not work either because the mapping to tell the driver to re-run the init isn't there.
For what it's worth - here's my changes and workarounds. https://github.com/mrfixit2001/rockchip-kernel/commit/4c7d778b184947ad14099592ac859edda8cff0a0
I'm sorry this is turning out to be so complicated to resolve. Will the next update still fix affected controllers, including the Trust GXT 540 Yula which is the one I use and have this problem with? If devices need to be manually registered in the module for initialization I'm fine with that, granted it works and someone will always be around to maintain the device list.
I'm sorry this is turning out to be so complicated to resolve. Will the next update still fix affected controllers, including the Trust GXT 540 Yula which is the one I use and have this problem with? If devices need to be manually registered in the module for initialization I'm fine with that, granted it works and someone will always be around to maintain the device list.
The dmesg you posted above shows the same product/vendor IDs that I have, and it's also using a shanwan manufacturer. The changes in my kernel repo would work for you.
Perhaps we can whitelist it using iManufacturer SHANWAN. I have attached the lsusb output of my controller.
thats actually a very good idea. I have updated the patch accordingly: https://github.com/paroj/xpad/commit/f44c551c7d4c91810ea0360459a19dbbfc5e81b8
please report back whether it works for you.
I also set MAP_TRIGGERS_TO_BUTTONS based on that - which will work until SHANWAN starts using real triggers..
I'll see how it goes once it reaches my kernel. Only problem is knowing when the patch is in: Building my own kernel is a bit advanced even for me and I don't want to mess up my system, thus I'm waiting for the patch to make it in. The controller still isn't initialized in 5.14.0 so I take it this might come in 5.15 at earliest.
you dont need to build your own kernel for this - just follow: https://github.com/paroj/xpad#installing
I just tested the new driver out on a stock install of Ubuntu 20.04. Except the triggers everything works. Pressing the triggers seem to do nothing.
I unloaded the new xpad driver and loaded the stock 5.8.0-43 kernel driver while the controller was connected and everything started working properly. So it seems that the control sequence is sent to the controller but something else broke the triggers. Maybe MAP_TRIGGERS_TO_BUTTONS is the culprit?
which will work until SHANWAN starts using real triggers.
this happened sooner than anticipated - dropped MAP_TRIGGERS_TO_BUTTONS again in master.
Ah that seems to have solved the problem. Everything seems to work now. I will use this driver for a while and update if I find something. Thanks a lot @paroj for the fix. Stuff tested
- KDE System Settings -Works: all buttons and axes detected
- Steam Big pricture - Works
- Vibration in Steam settings - works
SHANWAN 3 in 1 (X-Box 360, PS3, Android)
[ 395.206578] usb 2-1.2: new full-speed USB device number 6 using ehci-pci
[ 395.316436] usb 2-1.2: New USB device found, idVendor=2563, idProduct=0575, bcdDevice= 2.00
[ 395.316443] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 395.316448] usb 2-1.2: Product: PS3/PC Gamepad
[ 395.316451] usb 2-1.2: Manufacturer: SHANWAN
[ 395.322176] input: SHANWAN PS3/PC Gamepad as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/0003:2563:0575.0004/input/input23
[ 395.322417] hid-generic 0003:2563:0575.0004: input,hidraw0: USB HID v1.10 Gamepad [SHANWAN PS3/PC Gamepad] on usb-0000:00:1d.0-1.2/input0
[ 395.397075] usb 2-1.2: USB disconnect, device number 6
[ 396.018481] usb 2-1.2: new full-speed USB device number 7 using ehci-pci
[ 396.130484] usb 2-1.2: New USB device found, idVendor=045e, idProduct=028e, bcdDevice= 1.10
[ 396.130492] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 396.130496] usb 2-1.2: Product: Controller
[ 396.130499] usb 2-1.2: Manufacturer: SHANWAN
[ 396.131406] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/input/input24
[ 396.281339] usb 2-1.2: USB disconnect, device number 7
[ 396.281466] xpad 2-1.2:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19
[ 396.914444] usb 2-1.2: new full-speed USB device number 8 using ehci-pci
[ 397.025090] usb 2-1.2: New USB device found, idVendor=2563, idProduct=0526, bcdDevice= 1.00
[ 397.025097] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 397.025101] usb 2-1.2: Product: Android Gamepad
[ 397.025105] usb 2-1.2: Manufacturer: SHANWAN
[ 397.027848] input: SHANWAN Android Gamepad as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/0003:2563:0526.0005/input/input25
[ 397.028372] hid-generic 0003:2563:0526.0005: input,hidraw0: USB HID v1.10 Gamepad [SHANWAN Android Gamepad] on usb-0000:00:1d.0-1.2/input0
[ 397.030753] input: SHANWAN Android Gamepad System Control as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.1/0003:2563:0526.0006/input/input26
[ 397.090938] input: SHANWAN Android Gamepad Consumer Control as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.1/0003:2563:0526.0006/input/input27
[ 397.091248] hid-generic 0003:2563:0526.0006: input,hidraw1: USB HID v1.01 Device [SHANWAN Android Gamepad] on usb-0000:00:1d.0-1.2/input1
First it tries with Xbox 360, but as it doesn't send any input it goes to PS3 and then to Android, then by pressing the Home button I force it to the next mode which is again Xbox 360, it stays there but doesn't send any input until I run fixcontroller.py with this content:
for d in dev:
if d.idVendor == 0x045e and d.idProduct == 0x028e:
d.ctrl_transfer(0xc1, 0x01, 0x0100, 0x00, 0x14)
This every time the usb is connected...
I have tried to install the latest version with the indicated command without noticing any changes
sudo git clone https://github.com/paroj/xpad.git /usr/src/xpad-0.4
sudo dkms install -m xpad -v 0.4
PD:
RELEASE=20.3
CODENAME=una
EDITION="Xfce"
DESCRIPTION="Linux Mint 20.3 Una"
DESKTOP=Gnome
TOOLKIT=GTK
NEW_FEATURES_URL=https://www.linuxmint.com/rel_una_xfce_whatsnew.php
RELEASE_NOTES_URL=https://www.linuxmint.com/rel_una_xfce.php
USER_GUIDE_URL=https://www.linuxmint.com/documentation.php
GRUB_TITLE=Linux Mint 20.3 Xfce
I have tried to install the latest version with the indicated command without noticing any changes
you have to use the fantec branch
git clone -b fantech https://github.com/paroj/xpad.git /usr/src/xpad-0.4
[lun mar 14 16:17:05 2022] usb 2-1.2: new full-speed USB device number 4 using ehci-pci
[lun mar 14 16:17:05 2022] usb 2-1.2: New USB device found, idVendor=2563, idProduct=0575, bcdDevice= 2.00
[lun mar 14 16:17:05 2022] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[lun mar 14 16:17:05 2022] usb 2-1.2: Product: PS3/PC Gamepad
[lun mar 14 16:17:05 2022] usb 2-1.2: Manufacturer: SHANWAN
[lun mar 14 16:17:05 2022] input: SHANWAN PS3/PC Gamepad as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/0003:2563:0575.0003/input/input22
[lun mar 14 16:17:05 2022] hid-generic 0003:2563:0575.0003: input,hidraw0: USB HID v1.10 Gamepad [SHANWAN PS3/PC Gamepad] on usb-0000:00:1d.0-1.2/input0
[lun mar 14 16:17:05 2022] usb 2-1.2: USB disconnect, device number 4
[lun mar 14 16:17:06 2022] usb 2-1.2: new full-speed USB device number 5 using ehci-pci
[lun mar 14 16:17:06 2022] usb 2-1.2: New USB device found, idVendor=045e, idProduct=028e, bcdDevice= 1.10
[lun mar 14 16:17:06 2022] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[lun mar 14 16:17:06 2022] usb 2-1.2: Product: Controller
[lun mar 14 16:17:06 2022] usb 2-1.2: Manufacturer: SHANWAN
[lun mar 14 16:17:06 2022] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/input/input23
[lun mar 14 16:17:06 2022] usbcore: registered new interface driver xpad
[lun mar 14 16:17:06 2022] usb 2-1.2: USB disconnect, device number 5
[lun mar 14 16:17:06 2022] xpad 2-1.2:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19
[lun mar 14 16:17:07 2022] usb 2-1.2: new full-speed USB device number 6 using ehci-pci
[lun mar 14 16:17:07 2022] usb 2-1.2: New USB device found, idVendor=2563, idProduct=0526, bcdDevice= 1.00
[lun mar 14 16:17:07 2022] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[lun mar 14 16:17:07 2022] usb 2-1.2: Product: Android Gamepad
[lun mar 14 16:17:07 2022] usb 2-1.2: Manufacturer: SHANWAN
[lun mar 14 16:17:07 2022] hid-generic 0003:2563:0526.0004: unknown main item tag 0x3
[lun mar 14 16:17:07 2022] hid-generic 0003:2563:0526.0004: collection stack underflow
[lun mar 14 16:17:07 2022] hid-generic 0003:2563:0526.0004: item 0 0 0 12 parsing failed
[lun mar 14 16:17:07 2022] hid-generic: probe of 0003:2563:0526.0004 failed with error -22
[lun mar 14 16:17:07 2022] input: SHANWAN Android Gamepad System Control as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.1/0003:2563:0526.0005/input/input24
[lun mar 14 16:17:07 2022] input: SHANWAN Android Gamepad Consumer Control as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.1/0003:2563:0526.0005/input/input25
[lun mar 14 16:17:07 2022] hid-generic 0003:2563:0526.0005: input,hidraw0: USB HID v1.01 Device [SHANWAN Android Gamepad] on usb-0000:00:1d.0-1.2/input1
Thanks, but it doesn't work either, I see another error in Android mode but it's not the mode I want.
I have also tested the xpadone_paddles branch
[ 1253.360222] usb 2-1.2: new full-speed USB device number 4 using ehci-pci
[ 1253.470456] usb 2-1.2: New USB device found, idVendor=2563, idProduct=0575, bcdDevice= 2.00
[ 1253.470463] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1253.470468] usb 2-1.2: Product: PS3/PC Gamepad
[ 1253.470471] usb 2-1.2: Manufacturer: SHANWAN
[ 1253.473731] input: SHANWAN PS3/PC Gamepad as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/0003:2563:0575.0003/input/input22
[ 1253.474188] hid-generic 0003:2563:0575.0003: input,hidraw0: USB HID v1.10 Gamepad [SHANWAN PS3/PC Gamepad] on usb-0000:00:1d.0-1.2/input0
[ 1253.508110] usb 2-1.2: USB disconnect, device number 4
[ 1254.180186] usb 2-1.2: new full-speed USB device number 5 using ehci-pci
[ 1254.296088] usb 2-1.2: New USB device found, idVendor=045e, idProduct=028e, bcdDevice= 1.10
[ 1254.296095] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1254.296098] usb 2-1.2: Product: Controller
[ 1254.296102] usb 2-1.2: Manufacturer: SHANWAN
[ 1254.341624] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/input/input23
[ 1254.341891] usbcore: registered new interface driver xpad
[ 1254.423694] usb 2-1.2: USB disconnect, device number 5
[ 1254.423756] xpad 2-1.2:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19
[ 1255.076152] usb 2-1.2: new full-speed USB device number 6 using ehci-pci
[ 1255.186703] usb 2-1.2: New USB device found, idVendor=2563, idProduct=0526, bcdDevice= 1.00
[ 1255.186710] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1255.186714] usb 2-1.2: Product: Android Gamepad
[ 1255.186717] usb 2-1.2: Manufacturer: SHANWAN
[ 1255.189545] input: SHANWAN Android Gamepad as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/0003:2563:0526.0004/input/input24
[ 1255.190093] hid-generic 0003:2563:0526.0004: input,hidraw0: USB HID v1.10 Gamepad [SHANWAN Android Gamepad] on usb-0000:00:1d.0-1.2/input0
[ 1255.192558] input: SHANWAN Android Gamepad System Control as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.1/0003:2563:0526.0005/input/input25
[ 1255.252552] input: SHANWAN Android Gamepad Consumer Control as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.1/0003:2563:0526.0005/input/input26
[ 1255.252906] hid-generic 0003:2563:0526.0005: input,hidraw1: USB HID v1.01 Device [SHANWAN Android Gamepad] on usb-0000:00:1d.0-1.2/input1
https://www.amazon.es/gp/product/B07X5DZ8QS/