Some controllers that mimic the Xbox 360 Controller are not initialized correctly #119
Comments
This comment has been minimized.
This comment has been minimized.
|
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 The usb-devices command lists the controller as follows: Lastly for now here's the dmesg log piece after plugging in the device: |
|
@MirceaKitsune I think it can be automated with a udev rule. |
|
@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 |
|
@MirceaKitsune Write the following to a text file: |
|
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 2bfb0e1 |
|
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. |
this is not scheduled for upstream yet. You can use it with your current kernel as described here, though: |
Many knockoff brands emulating the XBOX 360 controller do not properly send data unless configured correctly. Examples include the Gamesir G3w and the Fantech GP11 Shooter. Protocol inspection of communication with other operating systems reveals a sequence of control messages that can be used to initialize the controllers sufficiently to send proper data. - fixes #119 - breaks #171 Proposed-by: Darvin Delgado <dnmodder@gmail.com>
|
moved the fix to a separate branch: I got reports that the change breaks other controllers in #171. |
|
Perhaps we can whitelist it using iManufacturer SHANWAN. I have attached the lsusb output of my controller. |
|
@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 - 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. Here's my output after adding the product/vendor to the device table with the proper mappings: 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. |
|
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. |
thats actually a very good idea. I have updated the patch accordingly: 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. |
|
I kinda have a similar problem. But instead of the controller switching from PS3->XBox, Fantech GP12 switches from PS3->Android on Linux machine. I use wireshark, on Windows it switch from PS3->Xbox, and the device plugged in sound triggers twice. From dmesg below, it seems like PS3 controller is initialized properly, but then switches to android immediately. Does PS3 controller have initialization code too? dmesg log |
|
In my controller I hold the home button to switch modes. Optionally hold X
button while the controller boots to go to xbox mode.
…On Fri, Jul 22, 2022 at 12:12 PM bradyhaley ***@***.***> wrote:
I kinda have a similar problem. But instead of the controller switching
from PS3->XBox, Fantech GP12 switches from PS3->Android on Linux machine. I
use wireshark, on Windows it switch from PS3->Xbox, and the device plugged
in sound triggers twice.
I wonder if Windows driver have special call so the switch order changes.
From dmesg below, it seems like PS3 controller is initialized properly,
but then switches to android immediately. Does PS3 controller have
initialization code too?
The android mode is working. But the mapping is horrible, right analog
doesn't work on wine, analog trigger and trigger button is pressed
simultaneously, making analog trigger useless.
dmesg log
[ +1,080919] usb 3-4.1: new full-speed USB device number 37 using xhci_hcd
[ +0,191723] usb 3-4.1: New USB device found, idVendor=2563, idProduct=0575, bcdDevice=52.00
[ +0,000003] usb 3-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ +0,000001] usb 3-4.1: Product: PS3/PC Gamepad
[ +0,000001] usb 3-4.1: Manufacturer: SHANWAN
[ +0,008941] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000005] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000003] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000004] hid-generic 0003:2563:0575.00CA: unknown main item tag 0x0
[ +0,000035] input: SHANWAN PS3/PC Gamepad as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4.1/3-4.1:1.0/0003:2563:0575.00CA/input/input296
[ +0,000174] hid-generic 0003:2563:0575.00CA: input,hidraw5: USB HID v1.10 Gamepad [SHANWAN PS3/PC Gamepad] on usb-0000:00:14.0-4.1/input0
[ +0,189500] usb 3-4.1: USB disconnect, device number 37
[ +0,598251] usb 3-4.1: new full-speed USB device number 38 using xhci_hcd
[ +0,192698] usb 3-4.1: New USB device found, idVendor=2563, idProduct=0526, bcdDevice= 1.00
[ +0,000016] usb 3-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ +0,000006] usb 3-4.1: Product: Android Gamepad
[ +0,000005] usb 3-4.1: Manufacturer: SHANWAN
[ +0,009759] input: SHANWAN Android Gamepad as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4.1/3-4.1:1.0/0003:2563:0526.00CB/input/input297
[ +0,000579] hid-generic 0003:2563:0526.00CB: input,hidraw5: USB HID v1.10 Gamepad [SHANWAN Android Gamepad] on usb-0000:00:14.0-4.1/input0
[ +0,001419] input: SHANWAN Android Gamepad System Control as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4.1/3-4.1:1.1/0003:2563:0526.00CC/input/input298
[ +0,055653] input: SHANWAN Android Gamepad Consumer Control as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4.1/3-4.1:1.1/0003:2563:0526.00CC/input/input299
[ +0,000125] hid-generic 0003:2563:0526.00CC: input,hidraw6: USB HID v1.01 Device [SHANWAN Android Gamepad] on usb-0000:00:14.0-4.1/input1
—
Reply to this email directly, view it on GitHub
<#119 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABZ3C3754FNIND7LERTO2FDVVI7E7ANCNFSM4GHWG6TA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
OMG That works! Thanks!! I should have tried it out... |
|
I tried holding the Home or X buttons even while plugging it in, no result. That python script is the only solution for my model. I'm still waiting for a permanent patch to finally make it into the kernel. |
|
Have you guys tried the fantech branch of xpad? https://github.com/paroj/xpad/tree/fantech |
This comment was marked as off-topic.
This comment was marked as off-topic.
Many knockoff brands emulating the XBOX 360 controller do not properly send data unless configured correctly. Examples include the Gamesir G3w and the Fantech GP11 Shooter. Protocol inspection of communication with other operating systems reveals a sequence of control messages that can be used to initialize the controllers sufficiently to send proper data. - fixes #119 - breaks #171 Proposed-by: Darvin Delgado <dnmodder@gmail.com>
Many knockoff brands emulating the XBOX 360 controller do not properly send data unless configured correctly. Examples include the Gamesir G3w and the Fantech GP11 Shooter. Protocol inspection of communication with other operating systems reveals a sequence of control messages that can be used to initialize the controllers sufficiently to send proper data. - fixes #119 - breaks #171 Proposed-by: Darvin Delgado <dnmodder@gmail.com>
|
I have a Trust GXT 540 (045e:028e) plugged in and set to Xinput mode. I have installed the xpad dkms module from the I'm currently on Linux Mint 20.3 Edge (kernel 5.15.0-48). lsusb and dmesg logs: ➜ sudo lsusb -v -d 045e:028e
Bus 003 Device 005: ID 045e:028e Microsoft Corp. Xbox360 Controller
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
idVendor 0x045e Microsoft Corp.
idProduct 0x028e Xbox360 Controller
bcdDevice 1.10
iManufacturer 1 SHANWAN
iProduct 2 Controller
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0030
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 93
bInterfaceProtocol 1
iInterface 0
** UNRECOGNIZED: 10 21 10 01 01 24 81 14 03 00 03 13 02 00 03 00
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 8
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0012
(Bus Powered)
Remote Wakeup Enabled
➜ dmesg | grep -A 5 "usb 3-2"
[ 613.301311] usb 3-2: USB disconnect, device number 3
[ 613.301420] xpad 3-2:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19
[ 613.624818] usb 3-2: new full-speed USB device number 4 using xhci_hcd
[ 613.789458] usb 3-2: New USB device found, idVendor=145f, idProduct=01c5, bcdDevice= 2.00
[ 613.789465] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 613.789467] usb 3-2: Product: Trust Gamepad
[ 613.789468] usb 3-2: Manufacturer: SHANWAN
[ 613.817635] input: SHANWAN Trust Gamepad as /devices/pci0000:00/0000:00:08.1/0000:0a:00.3/usb3/3-2/3-2:1.0/0003:145F:01C5.0005/input/input20
[ 613.817783] hid-generic 0003:145F:01C5.0005: input,hidraw3: USB HID v1.10 Gamepad [SHANWAN Trust Gamepad] on usb-0000:0a:00.3-2/input0
[ 616.435028] usb 3-2: USB disconnect, device number 4
[ 616.744813] usb 3-2: new full-speed USB device number 5 using xhci_hcd
[ 616.915327] usb 3-2: New USB device found, idVendor=045e, idProduct=028e, bcdDevice= 1.10
[ 616.915334] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 616.915336] usb 3-2: Product: Controller
[ 616.915337] usb 3-2: Manufacturer: SHANWAN
[ 616.940421] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:08.1/0000:0a:00.3/usb3/3-2/3-2:1.0/input/input21
|
|
Hmm modinfo reports a different .ko module file for xpad. I believe it's loading the kernel's native xpad module instead? ➜ modinfo xpad
filename: /lib/modules/5.15.0-48-generic/kernel/drivers/input/joystick/xpad.ko
license: GPL
description: X-Box pad driver
author: Marko Friedemann <mfr@bmx-chemnitz.de>
srcversion: 487C2C241DADE10B46F23B8...whereas dkms installs modified xpad under ➜ sudo dkms install -m xpad -v 0.4
Creating symlink /var/lib/dkms/xpad/0.4/source ->
/usr/src/xpad-0.4
DKMS: add completed.
Kernel preparation unnecessary for this kernel. Skipping...
Building module:
cleaning build area...
make -j16 KERNELRELEASE=5.15.0-48-generic KVERSION=5.15.0-48-generic...
Signing module:
- /var/lib/dkms/xpad/0.4/5.15.0-48-generic/x86_64/module/xpad.ko
Secure Boot not enabled on this system.
cleaning build area...
DKMS: build completed.
xpad.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/5.15.0-48-generic/extra/
depmod...
DKMS: install completed.
|
|
So here's the way I solved this: since the kernel was ignoring the driver installed under
The Trust gamepad is now working fine. 👍 All buttons, sticks and triggers (including sensitivity) events are being picked up by As expected dkms kept a back-up of the original kernel module when I installed xpad from source, so it can be restored safely if needed. It would be nice if the README included a note regarding this issue, so that users make sure where the original xpad install path is, if present, before installing. |
|
If anyone still having this problem is interested, feel free to give the modified xpad driver in my kernel a try. I pulled in some other changes and also made some changes of my own. In my tests everything is working for my different shanwan clones.
|
I don't know how and can't risk using custom kernels unfortunately. My OS is Manjaro in case it's relevant or helpful. I'm still hoping the fix makes its way to the vanilla kernel at last eventually. |
I would strongly advise against using a custom kernel just to get some fixes for a gamepad driver. |
|
I'm using the xpad update in kernel 6.0.arch1-1 (Repo - Testing) on Arch Linux and it's working perfectly. I use GNOME and have tested it on Steam, Lutris and the Heroic Game Launcher. My control is a generic SHANWAN. Thanks to @paroj and the other developers for their excellent work. |
That is wonderful news! Please put it into the standard kernel in this case: The rest of us experiencing the issue may get to benefit from it in the next 6.x update then. |
|
So, the current master on kernel 6.0 on Debian fails to properly initialize the Xiaoji Gamesir-G3w. The reason for this seems to be that the hid-generic driver “catches” it before it gets to xpad, after which the device resets and switches to mimic the 360 controller, but apparently the hid-generic device doesn't send the initialization packets correctly, not does xpad anymore, which manifests with the controller showing the correct number of axes and buttons but failing to send any packet (button presses and stick movements are not transmitted). If I add a comparison for |
|
After adding |
|
Sorry, the axis information may have been a glitch in jstest-gtk. However, the leds are still not working as expected. |
|
So I recently bought an X-input controller from 8BitDo facing a similar issue. Device is being recognized in USB but not working in xpad... it is not even creating an /dev/input file? (not listed in Any idea how to troubleshoot this? lsusb
...
Bus 001 Device 002: ID 2dc8:3106 8BitDo Ultimate Wireless Controllersudo lsusb -v -d 2dc8:3106
Bus 001 Device 002: ID 2dc8:3106 8BitDo Ultimate Wireless Controller
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
idVendor 0x2dc8 8BitDo
idProduct 0x3106
bcdDevice 1.14
iManufacturer 1 8BitDo
iProduct 2 Ultimate Wireless Controller
iSerial 3 5b1212d817e4
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0030
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 93
bInterfaceProtocol 1
iInterface 0
** UNRECOGNIZED: 10 21 10 01 01 24 81 14 03 00 03 13 02 00 03 00
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 8
Device Status: 0x0000
(Bus Powered)The information I get on connect: journalctl -f
Mai 07 14:24:57 mini-pc kernel: usb 1-3: New USB device found, idVendor=2dc8, idProduct=3109, bcdDevice= 2.00
Mai 07 14:24:57 mini-pc kernel: usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mai 07 14:24:57 mini-pc kernel: usb 1-3: Product: Ultimate Wireless Controller
Mai 07 14:24:57 mini-pc kernel: usb 1-3: Manufacturer: 8BitDo
Mai 07 14:24:57 mini-pc kernel: usb 1-3: SerialNumber: 5b1212d817e4
Mai 07 14:24:57 mini-pc kernel: hid-generic 0003:2DC8:3109.0004: hiddev96,hidraw3: USB HID v1.11 Device [8BitDo Ultimate Wireless Controller] on usb-0000:02:00.0-3/input0
Mai 07 14:24:57 mini-pc mtp-probe[3735]: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-3"
Mai 07 14:24:57 mini-pc mtp-probe[3735]: bus: 1, device: 6 was not an MTP device
Mai 07 14:24:57 mini-pc mtp-probe[3752]: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-3"
Mai 07 14:24:57 mini-pc mtp-probe[3752]: bus: 1, device: 6 was not an MTP device
Mai 07 14:26:39 mini-pc kernel: usb 1-3: USB disconnect, device number 6
Mai 07 14:26:40 mini-pc kernel: usb 1-3: new full-speed USB device number 7 using xhci_hcd
Mai 07 14:26:40 mini-pc kernel: usb 1-3: New USB device found, idVendor=2dc8, idProduct=3106, bcdDevice= 1.14
Mai 07 14:26:40 mini-pc kernel: usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mai 07 14:26:40 mini-pc kernel: usb 1-3: Product: Ultimate Wireless Controller
Mai 07 14:26:40 mini-pc kernel: usb 1-3: Manufacturer: 8BitDo
Mai 07 14:26:40 mini-pc kernel: usb 1-3: SerialNumber: 5b1212d817e4
Mai 07 14:26:40 mini-pc mtp-probe[3797]: checking bus 1, device 7: "/sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-3"
Mai 07 14:26:40 mini-pc mtp-probe[3797]: bus: 1, device: 7 was not an MTP device
Mai 07 14:26:40 mini-pc mtp-probe[3798]: checking bus 1, device 7: "/sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-3"
Mai 07 14:26:40 mini-pc mtp-probe[3798]: bus: 1, device: 7 was not an MTP deviceI used this script provided here in the thread in hopes to have it working correctly but it did not work. (script succeeded without issues though / also generated a rule ) cat /etc/udev/rules.d/99-gamesir-g3w-fix.rules
ACTION=="add", ATTRS{idProduct}=="3109", ATTRS{idVendor}=="2dc8", DRIVERS=="usb", RUN+="/usr/local/bin/gamesir-g3w-fix.py"adding also some additional info: sudo dmesg | grep -A 5 "usb 1-3"
[ 1.088920] usb 1-3: new full-speed USB device number 2 using xhci_hcd
[ 1.348623] ata2: SATA link down (SStatus 0 SControl 330)
[ 1.398401] tsc: Refined TSC clocksource calibration: 3599.998 MHz
[ 1.398414] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x33e451ab1a6, max_idle_ns: 440795278720 ns
[ 1.398454] clocksource: Switched to clocksource tsc
[ 1.457417] usb 1-3: New USB device found, idVendor=2dc8, idProduct=3106, bcdDevice= 1.14
[ 1.457422] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1.457424] usb 1-3: Product: Ultimate Wireless Controller
[ 1.457425] usb 1-3: Manufacturer: 8BitDo
[ 1.457426] usb 1-3: SerialNumber: 5b1212d817e4
[ 1.642400] usb 1-4: new full-speed USB device number 3 using xhci_hcd
[ 1.659808] ata5: SATA link down (SStatus 0 SControl 330)
[ 1.972093] ata6: SATA link down (SStatus 0 SControl 330)
[ 1.973479] Freeing unused decrypted memory: 2036K
[ 1.973904] Freeing unused kernel image (initmem) memory: 4360K
--
[ 516.782343] usb 1-3: USB disconnect, device number 2
[ 517.565300] usb 1-3: new full-speed USB device number 6 using xhci_hcd
[ 517.855313] usb 1-3: New USB device found, idVendor=2dc8, idProduct=3109, bcdDevice= 2.00
[ 517.855321] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 517.855324] usb 1-3: Product: Ultimate Wireless Controller
[ 517.855327] usb 1-3: Manufacturer: 8BitDo
[ 517.855329] usb 1-3: SerialNumber: 5b1212d817e4
[ 517.875203] hid-generic 0003:2DC8:3109.0004: hiddev96,hidraw3: USB HID v1.11 Device [8BitDo Ultimate Wireless Controller] on usb-0000:02:00.0-3/input0
[ 619.837990] usb 1-3: USB disconnect, device number 6
[ 620.620652] usb 1-3: new full-speed USB device number 7 using xhci_hcd
[ 620.991131] usb 1-3: New USB device found, idVendor=2dc8, idProduct=3106, bcdDevice= 1.14
[ 620.991137] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 620.991140] usb 1-3: Product: Ultimate Wireless Controller
[ 620.991143] usb 1-3: Manufacturer: 8BitDo
[ 620.991145] usb 1-3: SerialNumber: 5b1212d817e4modinfo xpad
filename: /lib/modules/6.2.12-200.fsync.fc37.x86_64/kernel/drivers/input/joystick/xpad.ko.xz
license: GPL
description: X-Box pad driver
author: Marko Friedemann <mfr@bmx-chemnitz.de>
alias: usb:v3285p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v3285p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v31E3p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v31E3p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v2F24p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v2F24p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v2E24p*d*dc*dsc*dp*icFFisc47ipD0in*
alias: usb:v2DC8p*d*dc*dsc*dp*icFFisc47ipD0in*
alias: usb:v260Dp*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v260Dp*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v2563p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v2563p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v24C6p*d*dc*dsc*dp*icFFisc47ipD0in*
alias: usb:v24C6p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v24C6p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v20D6p*d*dc*dsc*dp*icFFisc47ipD0in*
alias: usb:v20D6p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v20D6p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v1BADp*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v1BADp*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v1949p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v1949p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v1689p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v1689p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v162Ep*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v162Ep*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v15E4p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v15E4p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v1532p*d*dc*dsc*dp*icFFisc47ipD0in*
alias: usb:v1532p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v1532p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v146Bp*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v146Bp*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v1430p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v1430p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v12ABp*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v12ABp*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v1209p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v1209p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v11C9p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v11C9p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v1038p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v1038p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v0F0Dp*d*dc*dsc*dp*icFFisc47ipD0in*
alias: usb:v0F0Dp*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v0F0Dp*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v0E6Fp*d*dc*dsc*dp*icFFisc47ipD0in*
alias: usb:v0E6Fp*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v0E6Fp*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v0C12p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v0C12p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v07FFp*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v07FFp*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v0738p*d*dc*dsc*dp*icFFisc47ipD0in*
alias: usb:v0738p4540d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0738p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v0738p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v06A3p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v06A3p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v056Ep*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v056Ep*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v046Dp*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v046Dp*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v045Ep*d*dc*dsc*dp*icFFisc47ipD0in*
alias: usb:v045Ep*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v045Ep*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v044Fp*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v044Fp*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v03EBp*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v03EBp*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v0079p*d*dc*dsc*dp*icFFisc5Dip81in*
alias: usb:v0079p*d*dc*dsc*dp*icFFisc5Dip01in*
alias: usb:v*p*d*dc*dsc*dp*ic58isc42ip00in*
depends: ff-memless
retpoline: Y
intree: Y
name: xpad
vermagic: 6.2.12-200.fsync.fc37.x86_64 SMP preempt mod_unload
sig_id: PKCS#7
signer: Fedora kernel signing key
sig_key: 3B:72:B8:C1:F7:A2:06:4F:BD:05:AC:75:3A:D6:34:29:66:5D:4E:40
sig_hashalgo: sha256
signature: AC:16:42:35:92:22:D5:07:8B:25:D5:3C:58:0A:B6:F8:87:C3:5A:27:
AF:62:6C:1A:A0:8A:57:A1:C2:F5:23:FA:3F:75:B8:73:8B:AA:AB:FF:
54:BF:DF:32:84:E4:25:D0:0B:14:66:42:7C:5B:B1:DF:E6:66:D7:63:
04:AA:53:BA:F2:8D:4E:DD:44:61:8A:52:BE:48:41:14:43:F4:AF:9D:
D4:F8:22:BE:57:E0:12:A3:E0:5B:D2:5B:3B:B0:91:45:A3:97:23:61:
99:5D:65:2D:4F:B4:F3:12:DF:3E:A9:83:7D:42:CF:DB:48:24:A1:DD:
E4:BB:51:87:A4:6A:6D:0D:B4:5F:4A:58:6A:03:95:2F:6E:39:E0:06:
40:2D:BB:B7:E7:A2:76:3D:DB:8D:37:3E:C5:EA:AD:50:08:0E:07:19:
F2:4B:54:A8:7F:0C:03:2F:A5:B0:95:C6:F1:3B:03:BA:EB:6B:76:20:
DB:B4:25:7B:D5:88:D6:9E:B7:E9:A5:7B:BE:CF:FF:37:FE:14:DB:18:
38:88:D7:77:0B:B7:60:42:BD:25:56:54:D0:57:13:D9:77:EE:A7:F3:
4A:2B:5B:C7:98:36:43:73:45:6D:8E:33:B7:7B:CF:1F:B2:B4:F9:83:
EC:FA:FD:BA:12:DF:EA:90:07:30:34:99:C0:74:08:1F:D3:3D:FC:6E:
36:0A:BA:8B:F4:EA:10:98:C2:C8:CB:1E:DB:C3:55:47:5B:AC:AD:E8:
DA:ED:54:15:73:B6:E3:2F:6D:81:AD:9C:3F:88:9A:D2:A4:9F:ED:B4:
4A:4E:60:BB:CF:51:42:34:6E:0D:8A:DD:B2:62:19:3B:15:20:23:E1:
DC:3B:9A:F8:F7:FD:78:7C:AE:8C:04:A9:16:DA:FD:EA:3A:F3:6B:F6:
95:81:82:E0:50:1E:D5:F1:8C:5B:EE:2F:B6:F0:37:A3:F3:87:E3:FA:
B3:9A:AE:6B:62:95:B3:C2:F8:BA:1D:DD:81:EB:86:1A:8C:29:2C:2B:
99:8C:09:03:18:6D:38:8C:9C:97:E2:03:04:AC:23:CE:DF:B0:7A:08:
3C:B7:42:BA:B9:42:F9:5E:B6:A8:7F:D2:9E:34:27:8A:47:51:FB:71:
72:AD:BB:00:14:03:15:5C:99:EE:8C:FF:6A:6F:23:AC:C0:68:CA:43:
EB:65:92:47:B1:9A:90:55:63:97:D8:57:30:37:97:73:1A:A7:6C:E4:
E3:78:29:35:C2:F2:7F:17:D7:2D:F2:79:74:2E:BE:60:3B:B0:A8:16:
F8:82:52:34:03:E7:76:56:53:7D:5D:8B:C3:94:C6:A8:63:5E:5E:9E:
85:CC:2C:C1:52:44:01:BF:33:6C:E1:35
parm: dpad_to_buttons:Map D-PAD to buttons rather than axes for unknown pads (bool)
parm: triggers_to_buttons:Map triggers to buttons rather than axes for unknown pads (bool)
parm: sticks_to_null:Do not map sticks at all for unknown pads (bool)
parm: auto_poweroff:Power off wireless controllers on suspend (bool)What should I try next any ideas? In steam and in system settings no gamepad is found. (I guess because its not in /dev/inputs) |
dnmodder
changed the title
|
Hi, is there any chance for a driver for a wireless PC/PS3 gamepad that is identified under Linux as 2563:0526 (vendor:product)? The pad is named "SHANWAN Android Gamepad" and from what I found out it's made by ShenZhen ShanWan Technology. The Windows driver is [here (link)] (https://esperanza.pl/esperanza-gamepad-bezprzewodowy-2-4ghz-ps3-pc-usb-gladiator-czarny,176,1697.html). The gamepad offers rumble but it's not working under Linux, and also the analog/digital switch isn't working under Linux. I found a driver on GitHub (link) but it's for a different product ID, namely 2563:0575. The ShenZhen ShanWan Technology Co., Ltd webpage lists a few they make and I found a similar one here (link), but I don't have any information about the product number other than that mine is 2563:0526 but the webpage calls it BM-977. Any information is welcomed, maybe someone knows about a Linux driver somewhere. I found a python script (link) for another model, but it doesn't work for my product ID. Thanks! |
|
any workaround? |
|
The issue has been fixed for me! Manjaro is now on Kernel 6.7.7: My controller is recognized on the X-box setting automatically, no need to use the workaround Python script to reset it. Has the problem been solved for everyone? If others are still experiencing it, that must mean I'm among the lucky ones to get an exception for my model, an ideal solution should be universal and recognize all such devices. |
|
give me the python script pls |
|
|
Bus 005 Device 006: ID 2563:0526 ShenZhen ShanWan Technology Co., Ltd. Android Gamepad |
|
defernt ids in the script tho |
|
sometimes it appears as Bus 005 Device 002: ID 057e:2009 Nintendo Co., Ltd Switch Pro Controller |
|
Try holding down X while connecting the controller to usb
…On Thu, Apr 18, 2024, 1:13 AM SteavenGamerYT ***@***.***> wrote:
sometimes it appears as Bus 005 Device 002: ID 057e:2009 Nintendo Co., Ltd
Switch Pro Controller
—
Reply to this email directly, view it on GitHub
<#119 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABZ3C3YOHGVR2L46CTMUVG3Y55P7NAVCNFSM4GHWG6TKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBWGMYDONRWGA3Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
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.
The text was updated successfully, but these errors were encountered: