Gamepad suddenly not found on RPi3B+ w/ wired USB Piranha PC/PS2/PS3 (Clone) controller
-
@Raspburger The log shows the USB device disconnecting and resetting. That's why the controller doesn't work. Installing
xboxdrv
does not help if the device is not properly connected. -
@mitu said in Gamepad suddenly not found on RPi3B+ w/ wired USB Piranha PC/PS2/PS3 (Clone) controller:
@Raspburger The log shows the USB device disconnecting and resetting. That's why the controller doesn't work. Installing
xboxdrv
does not help if the device is not properly connected.Those messages were actually me disconnecting and re-plugging in the controller just to try out what dmesg says about it. Again, the controller works just fine on the Win7 PC. And, again, all other peripherals on the same USB lanes work just fine. So that's why the whole thing seems pretty odd - especially when taken into consideration the fact that just yesterday, the controller worked 100% on the RetroPie RPi3B+ build , including the analog controls and all!
-
After thinking of different scenarios and trying out different possible solution, I'm still ruling out the "bad USB cable / loose connection" theory for the very least. As said, other USB gamepads work just fine - which I would gladly use at this point, but I'm making this build copy for a special someone else. Anyhow, the controller is still working just fine on a Win7/64bit PC, where it is identified as a XBox360 Controller - which begs the question why the same thing happens on the RPi, but the controller will not work properly?
If it was a case of crappy electronics (which indeed would be the most likely culprit!), then what would account for the analog indicator LED to become lit for a few secs before going out after the USB lane clearly recognizes the controller? Let alone since it worked with nearly all emulators (I tried it on over 10 platforms) yesterday?
It's almost certainly some sort of a bug with the RPi/RetroPie build, either all the way to RPi's kernel or the joystick/USB drivers, OR, an issue with overall compatibility of the "Piranha" controller on the RPi. Either way, the controller stopped working so suddenly on the RPi (and without any user-made changes) that it baffles me what happened with it altogether.
Again, what was in that previously mentioned dmesg list was me plugging the controller in and out to see what would it show. I still cannot fathom how the controller stopped working on the RPi altogether so suddenly and unidentifiably - yet it's still working 100% on a Win7/64bit PC.
Now, after I've been trying to look into the recognized manufacturer ("SHANWAN") and their Linux support - I gotta say: sheesh, what a swamp! In all honesty, both the driver compatibility on Linux as well as the different configurations and layers upon layers of (possibly conflicting) packages with i.e. Emulationstation <-> RetroPie <-> RetroArch <-> Raspbian / Linux itself is even for "someone who has spent years in the profession" still mostly a tangled, confusing jungle to begin with.
There's also the possible conflicts of RetroPie's own setup and the drivers therein which can apparently cause certain types of controllers to stop working altogether, etc - just as it is warned about in the RetroPie setup menus for the individual controller driver packages.
I'm still wondering if all this hassle is because of the manufacturer that seems somewhat dodgy, since the one I have is indeed a knock-off PS3 controller ( reference: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Knockoff-PS3-Controllers )
The cable is a hardwired USB one, however, so I really dunno.
After re-installing a lot of the main/core components of RetroPie, no dice. Here's
dmesg
once again, with me unplugging and re-plugging the device back in:[ 1947.685106] usb 1-1.1.2: USB disconnect, device number 7 [ 1949.588124] usb 1-1.3: new full-speed USB device number 8 using dwc_otg [ 1949.723332] usb 1-1.3: New USB device found, idVendor=2563, idProduct=0575, bcdDevice= 2.00 [ 1949.723355] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1949.723364] usb 1-1.3: Product: PS3/PC Gamepad [ 1949.723374] usb 1-1.3: Manufacturer: SHANWAN [ 1949.736023] input: SHANWAN PS3/PC Gamepad as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:2563:0575.0003/input/input2 [ 1949.736746] hid-generic 0003:2563:0575.0003: input,hidraw1: USB HID v1.10 Gamepad [SHANWAN PS3/PC Gamepad] on usb-3f980000.usb-1.3/input0 [ 1950.668074] usb 1-1.3: reset full-speed USB device number 8 using dwc_otg [ 1950.798584] usb 1-1.3: device firmware changed [ 1950.799100] usb 1-1.3: USB disconnect, device number 8 [ 1950.978039] usb 1-1.3: new full-speed USB device number 9 using dwc_otg [ 1951.118577] usb 1-1.3: New USB device found, idVendor=045e, idProduct=028e, bcdDevice= 1.10 [ 1951.118594] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1951.118607] usb 1-1.3: Product: Controller [ 1951.118616] usb 1-1.3: Manufacturer: SHANWAN pi@retropie:~ $
Here's the device listing from lsusb -v :
Bus 001 Device 007: ID 045e:028e Microsoft Corp. Xbox360 Controller Couldn't open device, some information will be missing 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 iProduct 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 48 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
Now, since the controller is - as mentioned before - a third-party one, and since it supports both XBox360 and PS2/3 over the hardwired USB cable, I'm beginning to wonder if it is now somehow "in a wrong mode" for the RPi to recognize it properly [as I've mentioned, without the
xboxdrv
installed, it didn't show up at all). Maybe that's why the analog LED indicator light won't keep lit? Perhaps it's somehow mistakenly identfied either due to wrong/conflicting/bad drivers or just because the controller itself is somehow misbehaving with the available RPi/RetroPie drivers? -
Just a small addition on what I just found out: there seems to be a plethora of things to consider with these third-party/clone/knockoff PS3/Xbox360 controllers, at least according to the ArchLinux wiki:
https://wiki.archlinux.org/index.php/Gamepad#Using_generic/clone_controllers
Whew. Here we go, back into the swamp. I don't even know if I should start by i.e.removing
xboxdrv
and trying to (re-)install some of those ps3 drivers from RetroPie's Setup? I'm a bit worried that they still won't work as they're aimed more for the bluetooth controller types, not those with USB hard wiring. * sigh * Just like I noted in my previous post ...Oh, I forgot to mention, that I've replicated this same problem on two different Raspberry Pi 3B+ units now.
-
First, the
xboxdrv
is not a real gamepad driver - it's used to emulate an Xbox controller. So you can safely remove it.
Second, any Xbox 360 compatible controller are handled by thexpad
driver - which is the only gamepad driver installed with the RetroPie image. The rest of them are installed from the RetroPie-Setup, from the drivers section. If your controller claims to be an Xbox 360 controller, but it's not handled by thexpad
driver, then it might not work.
Third, Shanwan are a known brand of closed for the PS3 controller - they're supported through either thesixaxis
orps3controller
drivers. However, based on what you've experienced so far, it doesn't seem like those drivers would be needed.Looking through the
dmesg
output I can see that your particular device should be handled by thexpad
driver - https://github.com/paroj/xpad/blob/a66c53c008572db516a60a8d38ef4f823b3d3980/xpad.c#L139, but yourdmesg
output show that's handled by thehid-generic
module.Does the controller have a mode switch between PS2/PS3/PC ? Maybe it dynamically changes the VendorID/ProductID - first it shows as SHANWAN PS3/PC Gamepad, but later the
lsusb
output shows a Microsoft X360 controller. -
Ha! I found the workaround of the year without actually solving the problem with the driver(s).
Since the "Piranha" controller has a Y-cable so that it can be used to connect to a "classic" type PS2 (and perhaps PSX) controller port in addition to a USB port, I thought I'd try out a trick. I dug up a unit of one of those cheap, translucent-blue plastic adapters for two PSX/PS2 controllers and RetroPie working thru that one now, albeit I think there's a bit of an added latency in the controls. Hard to tell.
So, although the problem remains solved, there's your ~$5 USD workaround, should anyone be battling with the same issue. Note that in the case of the "Piranha" controller, whenever resorting to those PS2-USB adapters, always remember to turn on the analog option so that the indicator LED light will remain lit - it needs to be done before any keymapping et cetera, otherwise the gamepad won't function properly.
Should anybody have any tips on how to get the controller to work directly over USB, I'm still open for all suggestions on what to try. Thanks.
-
@mitu said in Gamepad suddenly not found on RPi3B+ w/ wired USB Piranha PC/PS2/PS3 (Clone) controller:
Does the controller have a mode switch between PS2/PS3/PC ? Maybe it dynamically changes the VendorID/ProductID - first it shows as SHANWAN PS3/PC Gamepad, but later the
lsusb
output shows a Microsoft X360 controller.First of all, thanks for the prompt reply and all the help so far! I really appreciate it :)
I've been thinking about that myself as well - the homepage of the manufacturer doesn't basically have any kind of a manual for the controller from where to look whether or not its modes can be switched just as you mentioned (i.e. through a button combination). That'd be one of my top bets in this case, as I was trying out different games last night and the controller suddenly went dead during one of my game tryouts just as I described earlier on. Perhaps, indeed, I managed to hit the "magic combination" to switch the mode, hard to tell. :P
I'm wondering if there's any online information on these PC/PS2/PS3-combo clone gamepads where I could find info on possible combinations that would change the mode of the controller? I'm such an old geezer in a sense that I've not been playing much console games since the first Playstation.
Thanks once again for the help and endurance, @mitu Megaman ^___^
-
After making sure that I had no redunant XBox360 drivers around, I tried to update xpad from source and got this error message:
Log started at: Sun 9 Jun 21:16:37 EEST 2019 RetroPie-Setup version: 4.4.14 (a86bd9e3) System: Linux retropie 4.19.46-v7+ #1231 SMP Mon Jun 3 17:42:48 BST 2019 armv7l GNU/Linux = = = = = = = = = = = = = = = = = = = = = Installing dependencies for 'xpad' : Updated Xpad Linux Kernel driver = = = = = = = = = = = = = = = = = = = = = /home/pi/RetroPie-Setup/tmp/build/xpad /home/pi = = = = = = = = = = = = = = = = = = = = = Getting sources for 'xpad' : Updated Xpad Linux Kernel driver = = = = = = = = = = = = = = = = = = = = = git clone --recursive --depth 1 "https://github.com/paroj/xpad.git" "/opt/retropie/supplementary/xpad" Cloning into '/opt/retropie/supplementary/xpad'... HEAD is now in branch 'master' at commit 'a66c53c008572db516a60a8d38ef4f823b3d3980' patching file xpad.c Hunk #2 succeeded at 1785 (offset 1 line). Successfully applied patch: /home/pi/RetroPie-Setup/scriptmodules/supplementary/xpad/01_enable_leds_and_trigmapping.diff /home/pi = = = = = = = = = = = = = = = = = = = = = Building 'xpad' : Updated Xpad Linux Kernel driver = = = = = = = = = = = = = = = = = = = = = ------------------------------ Deleting module version: 0.4 completely from the DKMS tree. ------------------------------ Done. Creating symlink /var/lib/dkms/xpad/0.4/source -> /usr/src/xpad-0.4 DKMS: add completed. Error! echo Your kernel headers for kernel 4.19.46-v7+ cannot be found at /lib/modules/4.19.46-v7+/build or /lib/modules/4.19.46-v7+/source.
Obviously, there's something going wrong with the xpad installation either due to the xpad source itself, or perhaps because of the kernel version I have, or a mix of both, or neither. Tried out the typical solutions offered on Raspberry Pi's forums ( https://www.raspberrypi.org/forums/viewtopic.php?t=219049 ).
First of all,
sudo apt raspberrypi-kernel
gives out the following return:pi@retropie:~ $ sudo apt install raspberrypi-kernel Reading package lists... Done Building dependency tree Reading state information... Done raspberrypi-kernel is already the newest version (1.20190517-1). raspberrypi-kernel set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Same thing goes for the
raspberrypi-kernel-headers
package:pi@retropie:~ $ sudo apt-get install raspberrypi-kernel-headers Reading package lists... Done Building dependency tree Reading state information... Done raspberrypi-kernel-headers is already the newest version (1.20190517-1). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
So, the next offered solution on the RPi forums ( https://www.raspberrypi.org/forums/viewtopic.php?t=154749 ) being
rpi-source
, I might just give that one a try while since I've started.... Just shout out a loud scream if it seems I'm doing something catastrophically wrong! :-)
-
@Raspburger You've run
raspi-update
and this pulled the latest testing Kernel, but this doesn't install the kernel-headers. Don't useraspi-update
unless you want to test something available in the latest test kernel -https://github.com/Hexxeh/rpi-update
You'll have to downgrade your kernel package to the one available in the Raspbian repositories in order to compile a kernel module. -
@mitu said in Gamepad suddenly not found on RPi3B+ w/ wired USB Piranha PC/PS2/PS3 (Clone) controller:
@Raspburger You've run
raspi-update
and this pulled the latest testing Kernel, but this doesn't install the kernel-headers. Don't useraspi-update
unless you want to test something available in the latest test kernel -https://github.com/Hexxeh/rpi-update
You'll have to downgrade your kernel package to the one available in the Raspbian repositories in order to compile a kernel module.He, there's always something! Just as I managed to install
xpad
by installingrpi-source
and hence the kernel headers (that didn't do anything, btw - even the controller still shows up as a Xbox360 controller although xpad is now properly installed). In any case, I guess it's back to downgrading then. Or, sticking with the "plan B workaround" PSX/PS2-to-USB-port adapter for now. Will keep you posted nonetheless. Cheers. -
Alright, I got the controller to work over USB without a hitch after there was a recent official update to the Raspberry Pi kernel.
I ran available all updates and removed the
ps3controller
&xboxdrv
controller packs just in case, with onlyxpad
now active, and it works like a charm now, straight over the USB port, so that there's no longer a need to use the PSX/PS2-to-USB adapter.Thanks for the support - keep up the good work! :)
-
Shouldn't have celebrated so early. I started to look into the drivers since I could only get one gamepad working, the other one was listed as a blank device in
lsusb
. Now, I'm back to square one, since the first controller is again recognized only as "Xbox360 Controller" and not working or recognized at all. The only thing that happens is when it's plugged into the USB port, the "analog" led indicator only lights up for a few seconds and then it turns off. Retropie doesn't recognize any gamepads.I think this might have to do something with the 4th of July RetroPie update that was mentioned at https://retropie.org.uk/news/ - the firmware/Raspbian update issue that's still ongoing.
I'd pull my hair out if I had any, "lol".
-
@Raspburger said in Gamepad suddenly not found on RPi3B+ w/ wired USB Piranha PC/PS2/PS3 (Clone) controller:
I think this might have to do something with the 4th of July RetroPie update that was mentioned at https://retropie.org.uk/news/ - the firmware/Raspbian update issue that's still ongoing.
That's highly unlikely, since the update affects mostly the firmware specific to the PI and not the kernel drivers.
-
@mitu said in Gamepad suddenly not found on RPi3B+ w/ wired USB Piranha PC/PS2/PS3 (Clone) controller:
First, the
xboxdrv
is not a real gamepad driver - it's used to emulate an Xbox controller. So you can safely remove it.
Second, any Xbox 360 compatible controller are handled by thexpad
driver - which is the only gamepad driver installed with the RetroPie image. The rest of them are installed from the RetroPie-Setup, from the drivers section. If your controller claims to be an Xbox 360 controller, but it's not handled by thexpad
driver, then it might not work.
Third, Shanwan are a known brand of closed for the PS3 controller - they're supported through either thesixaxis
orps3controller
drivers. However, based on what you've experienced so far, it doesn't seem like those drivers would be needed.Looking through the
dmesg
output I can see that your particular device should be handled by thexpad
driver - https://github.com/paroj/xpad/blob/a66c53c008572db516a60a8d38ef4f823b3d3980/xpad.c#L139, but yourdmesg
output show that's handled by thehid-generic
module.Does the controller have a mode switch between PS2/PS3/PC ? Maybe it dynamically changes the VendorID/ProductID - first it shows as SHANWAN PS3/PC Gamepad, but later the
lsusb
output shows a Microsoft X360 controller.HI again, so -- my current ordeal is that I got the controller to work directly over USB with the latest RetroPie build, but when I tried to connect two controllers of the same type directly via their USB cable (they have a Y-cable end for the connector, one is for PSX/PS2 type connection, and the other is for USB), it all went to hell.
They don't have a separate switch to swith between PS/PS2 and PC-USB mode, but I know whether or not they are working at all if the "analog" led indicator is lit or not (also, if the "analog" led will not light up even when pressing the button underneath the indicator, it means that the entire gamepad is completely undetected.)
Currently, neither of the controllers work and as I was probing thru the different problems related to HID USB drivers in Linux in general, I found out that there's been ongoing problems down to the Linux kernel level since January: https://github.com/atar-axis/xpadneo/issues/70
I think my issue might be related to that one. There's a conflict in game controller driver loading priority that goes all the way down to the Linux kernel level, and that's why whenever I plug the USB gamepad and the driver refuses to work, the led indicator will only light up for a few seconds and turns off by itself, without reacting to the analog on/off button afterwards.
sigh
-
@Raspburger said in Gamepad suddenly not found on RPi3B+ w/ wired USB Piranha PC/PS2/PS3 (Clone) controller:
Currently, neither of the controllers work and as I was probing thru the different problems related to HID USB drivers in Linux in general, I found out that there's been ongoing problems down to the Linux kernel level since January: https://github.com/atar-axis/xpadneo/issues/70
This is not a 'problem', but just a conflict between 2 drivers claiming the same device.
xpadneo
is an out-of-tree driver, which is not part of the Linux Kernel, so this kind of collision happens. However, this shouldn't affect your use case, sincexpadneo
works only for Bluetooth controllers. Furthermore, the Linux Kernel version available in Raspbian (and also in RetroPie) is now at 4.19, while the issue you mentioned is about Linux Kernel 4.20 (which incidentally doesn't exist, being replaced by 5.0 :) ). -
@mitu Ah, OK ! Thanks for the clarification on the Linux kernel version - I actually thought that the recent kernel update for the RPi did push us to the 4.20 kernel which has been talked about in other RPi circumstances for a while now, I guess I was just having a pipe-daydream :P
I will have to look further into the driver conflict - atm , this is what I get from
lsusb
anddmesg
:pi@retropie:~ $ lsusb
Bus 001 Device 009: ID 045e:028e Microsoft Corp. Xbox360 Controller
[ 415.782337] usb 1-1.2: New USB device found, idVendor=2563, idProduct=0575, bcdDevice= 2.00 [ 415.782352] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 415.782362] usb 1-1.2: Product: PS3/PC Gamepad [ 415.782372] usb 1-1.2: Manufacturer: SHANWAN [ 415.789460] input: SHANWAN PS3/PC Gamepad as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/0003:2563:0575.0005/input/input4 [ 415.790073] hid-generic 0003:2563:0575.0005: input,hidraw0: USB HID v1.10 Gamepad [SHANWAN PS3/PC Gamepad] on usb-3f980000.usb-1.2/input0 [ 416.693880] usb 1-1.2: reset full-speed USB device number 12 using dwc_otg [ 416.824353] usb 1-1.2: device firmware changed [ 416.824674] usb 1-1.2: USB disconnect, device number 12 [ 417.003906] usb 1-1.2: new full-speed USB device number 13 using dwc_otg [ 417.142096] usb 1-1.2: New USB device found, idVendor=045e, idProduct=028e, bcdDevice= 1.10 [ 417.142112] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 417.142122] usb 1-1.2: Product: Controller [ 417.142132] usb 1-1.2: Manufacturer: SHANWAN
You can see that it connects for a few seconds and then, for reasons beyond my comprehension, disconnects the device on its own. I have no idea what's going on in there, and the crazy part is that I already got one controller working without a hitch with the latest RetroPie update! I've tried uninstalling all controller drivers that came with RetroPie, using the RetroPie Setup script.
Thanks a lot for the help & patience!
-
@mitu said in Gamepad suddenly not found on RPi3B+ w/ wired USB Piranha PC/PS2/PS3 (Clone) controller:
Does the controller have a mode switch between PS2/PS3/PC ? Maybe it dynamically changes the VendorID/ProductID - first it shows as SHANWAN PS3/PC Gamepad, but later the lsusb output shows a Microsoft X360 controller.
Sorry, missed this one.
The controller doesn't have a switch between PS2/PS3/PC mode - the only indicator for it being powered on is the red analog LED which should be lit at all times, or light up when you push the analog on/off button underneath the light.
Right now, I'm back to square one as it's doing what it did originally, which was to for the the indicator light to turn on for a few seconds when the USB cable is plugged, and then it goes dead silent. That behavior is visible also in the previously posted
dmesg
error message.It's absolutely insane that I already got it working on RetroPie 100% oknp over the USB connection, then I noticed that having two of the same type of those controllers would not work at the same time, and as I began reconfiguring the drivers from RetroPie's setup, it all went to hell, and now I can't even make one controller to work. I've tried uninstalling all drivers that came with RetroPie and re-installing i.e.
ps3controller
w/ Shanwan support separately, as well assixaxis
separately, to no avail. I wonder if there's some kind of a conflict with some driver package that "forces" the controller to be recognized as an XBox360 Controller? -
@mitu said in Gamepad suddenly not found on RPi3B+ w/ wired USB Piranha PC/PS2/PS3 (Clone) controller:
Looking through the dmesg output I can see that your particular device should be handled by the xpad driver - https://github.com/paroj/xpad/blob/a66c53c008572db516a60a8d38ef4f823b3d3980/xpad.c#L139, but your dmesg output show that's handled by the hid-generic module.
Alright, so having tried out this, that and the other option, I think that might be the culprit here.
Does anyone know if there's an easy way to force a bypass to
hid-generic
when a particular USB device is plugged in (in this case, either of the identical gamepad controllers that I'm struggling with) , so that those devices would be handled one of those formentioned, i.e.xpad
,ps3controller
,sixaxis
... ? -
I'm at my wits' end here. I've tried blacklisting the device to prevent it being grabbed by
usbhid
by creating/etc/modprobe.d/blacklist.conf
and adding to it :blacklist usbhid
No dice.
I've tried creating:
/etc/udev/rules.d/99-disable-usb-hid.rules
and adding to it:
SUBSYSTEMS=="usb", DRIVERS=="usbhid", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="028e", ACTION=="add", ATTR{authorized}="0"
No dice.
Before that, tried adding an
/etc/udev/rules.d/
ruleset with:SUBSYSTEM=="usb",ATTRS{idVendor}=="045e", ATTRS{idProduct}=="028e", MODE="666", GROUP+="plugdev"
No dice.
The end result is always the same, reboot after reboot. I've tried looking at other conf files in
/etc/udev/rules.d/
to see that there are no conflicts.I have two identical controllers at my disposal I've tried plugging them in one at a time. Adding to that, I've tried this with FOUR identical controllers, all of which work 100% plug'n'play in Windows 7.
The controller's analog LED light lights up for a few seconds and then shuts off.
Here's what
lsusb -v -s 001:009
shows :pi@retropie:~ $ lsusb -v -s 001:009 Bus 001 Device 009: ID 045e:028e Microsoft Corp. Xbox360 Controller Couldn't open device, some information will be missing 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 iProduct 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 48 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 pi@retropie:~ $
All help appreciated. This is especially infuriating as I already got this thing to work once with one controller, tried to get it working with two controllers of the same kind, and it all went to hell. * one huge sigh *
Am I completely on a wrong track here if I'm thinking that perhaps the device ID should be added into the boot config file or somewhere alike as separately blacklisted or as an USB HID exception? Or, does the actual problem run deeper somewhere on the Raspbian/Linux kernel level? That's what a lot of my attempts to search further into the USB HID device issues w/ Linux altogether would suggest.
One plausible culprit might also be that since the controller ( http://piranha-gamer.com/product/piranha-pc-ps2-ps3-controller/ ) is listed as a "PC/PS2/PS3" controller, it might auto-select its operating mode accordingly between PC and PS mode upon being plugged to an USB port. Then again, that doesn't explain how it has worked earlier from time to time (or, should I say, from RetroPie update to RetroPie update) without any problems whatsoever.
-
Hi Raspburger,
I have been trying the same Piranha controller with both my PC and Ubuntu and a Raspberry Pi 3B with a full Raspbian and had exactly the same problem as you describe. I have seen in this topic that you mentioned a hotkey that could switch the controller between PS3 and XBOX modes and after a few minutes trying I found that holding "Analog" button for 5-10 seconds actually forced the controller to initialize as PS3, and it works out of the box now on both my Ubuntu and Raspberry Pi/Raspbian.
Hope this helps.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.