Open hellpe opened 5 years ago
Hi,
I'm having the same problem after upgrading to Fedora 29 (kernel 4.18.16-300.fc29). The workaround works too. I tested with two old kernels from Fedora, 4.18.14-200.fc28 and 4.18.16-200.fc28 and it fails with both of them too so I'm thinking the issue is actually somewhere else. I've not been able to figure out where yet.
What I've gathered so far is that -2 corresponds to this error, so I've looked at the /sys
directory logged by dmesg and indeed there's no input directory
:
Nov 05 20:06:01 foo kernel: input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-4/1-4:1.0/input/input16
Nov 05 20:06:01 foo kernel: usbcore: registered new interface driver xpad
Nov 05 20:06:01 foo kernel: xpad 1-4:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -2
in the directory:
$ ll /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-4/1-4:1.0/
total 0
-rw-r--r--. 1 root root 4.0K Nov 5 20:06 authorized
-r--r--r--. 1 root root 4.0K Nov 5 20:06 bAlternateSetting
-r--r--r--. 1 root root 4.0K Nov 5 20:06 bInterfaceClass
-r--r--r--. 1 root root 4.0K Nov 5 20:06 bInterfaceNumber
-r--r--r--. 1 root root 4.0K Nov 5 20:06 bInterfaceProtocol
-r--r--r--. 1 root root 4.0K Nov 5 20:06 bInterfaceSubClass
-r--r--r--. 1 root root 4.0K Nov 5 20:06 bNumEndpoints
drwxr-xr-x. 3 root root 0 Nov 5 20:06 ep_01/
drwxr-xr-x. 3 root root 0 Nov 5 20:06 ep_81/
-r--r--r--. 1 root root 4.0K Nov 5 20:06 modalias
drwxr-xr-x. 2 root root 0 Nov 5 20:06 power/
lrwxrwxrwx. 1 root root 0 Nov 5 20:06 subsystem -> ../../../../../../../bus/usb/
-r--r--r--. 1 root root 4.0K Nov 5 20:06 supports_autosuspend
-rw-r--r--. 1 root root 4.0K Nov 5 20:06 uevent
and after rmmod xpad && modprobe xpad
:
$ ll /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-4/1-4:1.0/
total 0
-rw-r--r--. 1 root root 4.0K Nov 5 20:06 authorized
-r--r--r--. 1 root root 4.0K Nov 5 20:06 bAlternateSetting
-r--r--r--. 1 root root 4.0K Nov 5 20:06 bInterfaceClass
-r--r--r--. 1 root root 4.0K Nov 5 20:06 bInterfaceNumber
-r--r--r--. 1 root root 4.0K Nov 5 20:06 bInterfaceProtocol
-r--r--r--. 1 root root 4.0K Nov 5 20:06 bInterfaceSubClass
-r--r--r--. 1 root root 4.0K Nov 5 20:06 bNumEndpoints
lrwxrwxrwx. 1 root root 0 Nov 5 20:08 driver -> ../../../../../../../bus/usb/drivers/xpad/
drwxr-xr-x. 3 root root 0 Nov 5 20:06 ep_01/
drwxr-xr-x. 3 root root 0 Nov 5 20:06 ep_81/
drwxr-xr-x. 3 root root 0 Nov 5 20:08 input/
-r--r--r--. 1 root root 4.0K Nov 5 20:06 modalias
drwxr-xr-x. 2 root root 0 Nov 5 20:06 power/
lrwxrwxrwx. 1 root root 0 Nov 5 20:06 subsystem -> ../../../../../../../bus/usb/
-r--r--r--. 1 root root 4.0K Nov 5 20:06 supports_autosuspend
-rw-r--r--. 1 root root 4.0K Nov 5 20:06 uevent
but after that I have not investigated further.
I'm positive it worked with Fedora 28 with the 4.18.16 kernel so I'm not sure what changed.
Hi, had a quick look at the issue, since I can reproduce it with openSUSE tumbleweed and kernel v4.20-rc1. It seems that just after probing the device fwupd is unbinding it for god knows what reason. I bet there is a race condition between probing and that really fast unbind. In order to test what I'm talking about just run the following command and insert the controller:
sudo service fwupd stop
I'll try to provide a fix in the driver as soon as I have the time.
Hey @vianpl, just to let you know, stopping fwupd before inserting the controllers does indeed work. Thanks !
Well the issue was fixed in fwupd. We just have to wait for distros to pick up the changes. There is no need to patch xpad.
I have a similar problem, my Fantech GP11 command, which is recognized as an Xbox 360 controller, does not generate keystroke events, nothing at all, this is a problem of Xpad, since it should send certain codes to the command, but he does not, how do I know that, they ask? I revise the Windows driver; if I send the codes manually with a script that I did in python it works, but it's annoying to have to do that every time I'm going to play.
This was translated from Spanish, sorry if something is not understood, but I would appreciate your help.
dnmodder, what distro are you using? Could you try to run this command with the controller unplugged?
sudo service fwupd stop
And then connect the device. It should work.
I already tried that and it did not work, as I said before, it only works when I send the codes, through a ctrl_transfer.
https://gist.github.com/dnmodder/de2df973323b7c6acf45f40dc66e8db3
There I leave the file for you to look at it, I think that this should be included in the driver, but not needing other controllers, they did not put it.
I see, I think you should open a new issue then. As this one isn't really related.
I had already done it, but I do not know if due to lack of information, nobody answered my problem, so I apprehended this one to ask for help, then, did I eliminate the one I already had or update it?
I have a similar issue (I think). Tested and reproduced it on many distros and versions, but it all seems to result in the same behavior.
The weird part is, that my controllers (for some reason) simply need an initial setup to work. If I boot into Windows, let it configure the device and then boot into Ubuntu without unplugging the power on my USB-hub, they work perfectly fine - until I unplug them.
BTW: They're knock-off PS3-USB-controllers
try #120
git checkout -b Oblomov-init-360-control master
git reset --hard https://github.com/Oblomov/xpad.git init-360-control
Thanks @dnmodder #118 in combination with the modprobe xpad off/on works. (That is, plug in the device, modprobe-spiel and then you Python-script)
Edit: @paroj, am I interpreting #120 right that this is basically the proper fix for the workaround in #118?
I did it this way:
sudo git clone https://github.com/Oblomov/xpad.git /usr/src/xpad-0.4
cd /usr/src/xpad-0.4
git checkout init-360-control
sudo dkms install -m xpad -v 0.4
Works perfectly fine after a reboot @dnmodder.
Hello, My controller rumble did not work on Ubuntu but did work Windows. I had to remove the 3rd control message or it would crash the controller.
[Controller] idVendor=045e, idProduct=028e, bcdDevice= 1.10 Product: XBOX 360 For Windows Manufacturer: CHIPUNION Co.,Ltd I bought it at a Action store.
Its a pcap from windows usbpcap (that works) windows.txt
Its a pcap from ubuntu with branch init-360-control ubuntu.txt
You can see on Ubuntu, the last packet has an error: URB status: Protocol error (-EPROTO) (-71)
As I don't do Kernel, I don't really understand why it fails.
[Edit] Well I also removed the 2nd control message or I couldn't receive any input. With only the 1st control message, I have input & rumble
I had same issue on my Fantech GP12 revolver. Fixed it by using the commands : sudo rmmod xpad and sudo modprobe xpad as mentioned above.
Wanted to say installing xpad 0.4 made my controller work too. It was indeed a generic x360 clone.
I had same issue on my Fantech GP12 revolver. Fixed it by using the commands : sudo rmmod xpad and sudo modprobe xpad as mentioned above.
I have the same controller, what command are you executing? I've tried Oblomov init-360-control xpad-0.4, but no avail.
This controller is weird, each time I connect & disconnect, It seems changing mode, from Xbox, PS3, and Android. And sometimes it get detected with lsusb, sometimes not. I ony get dmesg output from usb, none xpad, sometimes usbhid.
Connecting to windows machine always works.
And connecting to zorin os, it detected as android gamepad! and it works! I wonder if this have something to do with udev and manjaro itself.
After checking dmesg in zorin. it seems cycling between modes, if one fail, then it get to the next mode. And in manjaro, it does not cycling.
My dmesg says
[ 722.154170] usb 1-4: USB disconnect, device number 25
[ 722.154252] xpad 1-4:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19
[ 745.736226] usb 1-2: new full-speed USB device number 26 using xhci_hcd
[ 745.886160] usb 1-2: device descriptor read/64, error -71
[ 746.156200] usb 1-2: device descriptor read/64, error -71
[ 746.426306] usb 1-2: new full-speed USB device number 27 using xhci_hcd
[ 746.576127] usb 1-2: device descriptor read/64, error -71
[ 746.846129] usb 1-2: device descriptor read/64, error -71
[ 746.966171] usb usb1-port2: attempt power cycle
Something thats strange is I have two xbox360 controllers, one of which I bought from a legit xbox store, and one that I got... elsewhere, and the real one is the one that doesnt work.
Its not a hardware issue because it works on macOS.
Ive also noticed that if I plug it in while KWin is on the splash screen, it works for a while, but then it just.... stops producing input.
I dont have the service
command, but systemctl stop fwupd
doesnt help.
rmmod xpad && modprobe xpad
does nothing, too.
same here. i get this after running wine.
sudo modprobe xpad
I had same issue on my Fantech GP12 revolver. Fixed it by using the commands : sudo rmmod xpad and sudo modprobe xpad as mentioned above.
This solution fix my issue too (Fantech GP12 revolver). From what I notice, it change the joystick from Android to PC mode. Thank you
This happens to me every single time I run a game on Wine. to live with it, I made a crappy script that does rmmod xpad; modprobe xpad
and I run it every time after running a game, only then the controller works just fine.
fwupd is obviously up to date as I'm running Arch. Also running the latest Git version of this driver from this master branch.
I wonder what's the deal with this?
I'm having the same issue with xpad + wine.
I don't need to rmmod xpad
but I do need to close all wine, and do modprobe xpad
.
Hello,
It's been several weeks since I noticed that my Xbox 360 wired controllers stopped working on Arch Linux (my current kernel version is 4.18.12). When plugging them in,
dmesg
displays the following error:I've found a workaround: by doing
sudo rmmod xpad
thensudo modprobe xpad
, the controller works again. But if I'm unplugging it then plugging it back, the following error messages show up indmesg
:I've tried the git version of xpad (provided by https://aur.archlinux.org/packages/xpad-dkms-git/) but the issue is still present. The SteamOS version of xpad (https://aur.archlinux.org/packages/steamos-xpad-dkms/) has the same buggy behaviour, except the four LEDs of the gamepad are blinking, whereas upstream xpad only shows the 1st LED statically lit. Also, I've tested the controllers on Windows on the same machine and they work perfectly, so I don't think this is hardware related.