Gamepad suddenly not found on RPi3B+ w/ wired USB Piranha PC/PS2/PS3 (Clone) controller

Raspburger

@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 use raspi-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 installing rpi-sourceand 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.

Raspburger

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 only xpad 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! :)

Raspburger

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".

mitu

@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.

Raspburger

@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 the xpad 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 the xpad driver, then it might not work.
Third, Shanwan are a known brand of closed for the PS3 controller - they're supported through either the sixaxis or ps3controller 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 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.

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

mitu

@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, since xpadneo 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 :) ).

Raspburger

@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 and dmesg :

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!

Raspburger

@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 as sixaxis 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?

Raspburger

@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 ... ?

Raspburger

I'm at my wits' end here. I've tried blacklisting the device to prevent it being grabbed by usbhidby 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.

bis0n

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.

AJenbo

I have the same awful controller. It tries to detect the device that it's connected to and select mode based on that. If the system is running Windows it will switch to Xbox mode.

I'm still not sure how exactly to switch mode, but last I got I working by holding select+analog. But I also found this on a sellers website:
"press the "home" button for 7 seconds, you can freely switch the mode."

Linux actually seams able to use the gamepad in all 3 modes (it also has an Android mode), but the device sometimes won't fully register before switching the mode a couple of times.