New controller detected by Emulationstation but not working in Retroarch

[mitu]

@danno said in New controller detected by Emulationstation but not working in Retroarch:

but it wasn't showing enabled in the setup script.

Yes, I think it's only for the Pi images.

Is there another way I can confirm xboxdrv is not running?

Look in the process list and see if anything is listed

ps -ef | grep xboxdrv

[Danno]

That gives back an entry, but I believe it is the process for the 'ps' command itself (because 'xboxdrv' is passed as a string to grep):

If I open XFCE task manager and search through "all processes" for 'xboxdrv', (or even 'xbox'), nothing is shown.

Does that sound reasonable?

[mitu]

@danno said in New controller detected by Emulationstation but not working in Retroarch:

Does that sound reasonable?

Yes, it's clearly not running anymore. Can't explain why it's not showing up in the list of devices.
Can you try to get a log from the device detection ? Unplug the device, then run

sudo dmesg -c
sudo dmesg -w

then plug back the device. Get the output of the kernel log from the last command, then press Ctrl +C to stop the monitoring. Post the detection messages in the topic.

[Danno]

@mitu - Thanks for your continued help. Here is the kernel output produced when plugging in the controller. As you'll see, there is a recurring error from the xpad driver:
xpad 2-2:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19

This is a bit above my level of Linux expertise, but a bit of searching led me to this fairly-similar issue in Github: https://github.com/paroj/xpad/issues/114. Please take a look and see what you think.

It may be worth mentioning again: The xpad driver I installed from source using the Retropie-Setup utility this past weekend is still in place. I'll wait to hear your feedback first, but am wondering if that could also be a factor.

[mitu]

@danno the xpad driver being installed is fine. The kernel log shows the connection to the device is erratic and the communication is not lost before xpad tries to query the device:

[24649.761245] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:10.0/usb2/2-2/2-2:1.0/input/input181
[24651.268951] usb 2-2: USB disconnect, device number 39
[24651.269877] xpad 2-2:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19

Can you try a different cable/USB port to see if maybe the connection remains stable ?

[Danno]

@mitu Though I am confident the USB port being used is good because when the PC was my wife's Windows PC, it had our weather station connected to the same port and that never encountered any issues, I went ahead and tested 2 other USB ports...they give the same recurring error in DMESG.

Just for 'fun', I tried one of the suggestions given in the GitHub issue I linked above, sudo service fwupd stop, before plugging in the controller, but that didn't work. I didn't mention it in my initial post, but the arcade PC is on kernel 5.4.0-64-generic.

The controller defaults to running in D-INPUT mode. I thought it might be interesting to see what happens when switching it to X-INPUT mode, so I gave that a try with DMESG watching. However, I found that holding the menu button in for 7 seconds did not switch modes for the controller. I then launched Emulationstation and tried again and then I was able to successfully switch to X-INPUT mode there (remember - Emulationstation also had no problems configuring the controller and displaying the correct keys pressed).

However, when I exited ES to look at the DMESG output, the controller immediately went back to D-INPUT mode (there is an LED that lights up in X-INPUT mode, which turned off). Not sure if this info is helpful, but I am curious why ES seems to detect the controller properly while Retroarch and the kernel seem to have issues with it.

[mitu]

@danno That's weird. EmulationStation uses SDL to communicate with the controller and - for the most part - that's relying on the OS. There is a way to bypass the kernel driver (via HIDAPI) built into SDL, but that's just for recent versions.

You can try switching the input_driver in /opt/retropie/configs/all/retroarch.cfg from udev to sdl2 and see if that changes anything in RetroArch.

[Danno]

@mitu Just to clarify: Currently in the retroarch.cfg file, the line for input_driver is commented out (value of 'sdl'), and input_joypad_driver is set to "udev". is Input_joypad_driver the variable that should be changed to "sdl2" for the test?

And, does the CFG file in retroarch-joypads for the controller need input_driver changed as well?

[mitu]

Yes, that's the one (input_joypad_driver).

And, does the CFG file in retroarch-joypads for the controller need input_driver changed as well?

Haven't though about that - but I think yes, they should be in-sync.

[Danno]

Based on your comments and some other forum posts, I decided to leave the global retroarch.cfg file alone for now, and updated the config file for the controller in retroarch-joypads to include these lines:

# input_driver = "udev"
input_driver = "sdl2"
input_vendor_id = "1118"
input_product_id = "654"

Afterward when launching the game, the pop-up from Retroarch showed the controller now successfully connected on port 1, instead of "not configured" like before. Also, the buttons were being recognized by RA in the quick menu to configure input mappings. But, when playing the game, they didn't seem to behave as expected, especially the steering wheel itself, which had no effect at all.

I didn't have much time during lunch to try much else, but I feel I may about to be sucked down a very long rabbit hole. I'm going to try and think and research a bit more to come up with a more-structured game plan, but am interested in any thoughts you may have with this new info.

[mitu]

@danno To be honest, I'm not sure how RetroArch and/or SDL support steering wheels.
I know SDL has some haptic controller support, but the sdl2 joypad input driver in RetroArch is not something that's used regularly, and it's more of a last resort option when the native platform's drivers are having issues (just like this case). Consequently, it may lack features present in the default (udev for Linux) input driver.

So, it's up to you if you want to continue testing the controller. There's a handy utility (sdl2-jstest) that you can use to test the capabilities of the controller and find out if the steering wheel would be supported.

[Danno]

I spent several hours this past weekend working on the controller issue, and as the saying goes, I've got some good news and I've got some bad news....

On the "good news" side of things: I did some further searching online and targeted the specific vendor and product IDs (idVendor=045e, idProduct=028e) that the kernel was showing for this controller.
I found a few other users posting the exact same problem with xpad continually issuing the error every few seconds:

xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19.

In each case, the user resolved this by using xboxdrv instead, so I gave it a try.

First, I tried using the Retropie-Setup script to reinstall the xboxdrv driver, but had a few issues doing it that way. One was that the script said it was modifying rc.local when I chose the "Enable" option, but I didn't find rc.local on my machine afterward (I think rc.local is depracated in favor
of systemd these days). And, trying to run xboxdrv manually from the terminal resulted in a "command not found" error. So, I reversed what I did, and instead just installed xboxdrv from the repos by
Sudo apt-get install xboxdrv. That seemed to work.

Next, I plugged the controller in and confirmed the xpad error showing every few seconds as it's been doing, and then issued this command: /usr/bin/xboxdrv --detach-kernel-driver --silent.
I had to issue the command a few times in succession, but eventually it showed the contoller being detected:

Your Xbox/Xbox360 controller should now be available as:
/dev/input/js0
/dev/input/event25

Also, the errors from xpad stopped immediately afterward. So, I launched ES and tried Spy Hunter as a test, and found that none of the buttons on the controller were responding. And, not even the (bluetooth) keyboard
was being recognized any more, so pressing Tab did nothing. I unplugged the controller, exited out and repeated the above steps. But, this time, once I got into ES, I switched the controller from D-input to X-Input mode. Now, the controller ID changed from "Xbox 360 Contoller" to "CHIPUNION USB Racing Wheel".

I configured it again in ES (process seemed identical to configuring it as an Xbox 360 Controller), and now when I went into Retroarch (LR-MAME2003) and brought up the RGUI menu, I was able to configure the Retropad bindings, and also the 'quick' menu mappings. That's where the "good news" ends.

The "bad news" - in spite of my efforts that lasted over an hour, I could not configure / calibrate the controller to work well in the game. The 2 main controller axis controls, the wheel and (gas) pedal, didn't seem to respond to my adjustments. Which is frustrating, as the spinner control on my main controller responded to adjustments as expected. Unfortunately, it is too difficult to manage all of the different inputs using the spinner and a bunch of buttons, which is why I bought the steering wheel controller
(which also has triggers on the yoke - those did configure properly for machine gun, missle, etc).

I had hoped to also use the wheel with other games like Paperboy and Pole Position, but the control and sensitivity of the wheel/pedal axes seem to be defying me. Not sure what I'll do, but I'm leaning toward setting the controller aside from now, and waiting for Retropie to update again as there are some other controller-related fixes in the latest version of Retroarch that I'm waiting for (later than v 1.8.8, which is what Retropie 4.7.1 currently includes). There's also the task of automating the xboxdrv command each time I want to play a game with the wheel.

I'll post back if I eventually get this working. Of course, I'm still open to other suggestions....

[Danno]

Just found a review for this controller on Amazon (under a different brand/manufacturer name), which seems to confirm my findings:

CONS
There are not too many Cons about this Wheel, just one big one and a few annoyances.
Pressure Sensitive- on the PS3 the Pedals register as X and Square. Which means that you do not get the pressure from R2. This is also the case in some games on PC when using the Wheel in Mode 2. This makes it nearly impossible to play most racing games. Grid 2 was impossible to play and very frustrating. When you press the gas you just spin out of control.

Reviewer even mentioned trying controller in Retroarch. Wish I had seen that before purchasing. Still haven't given up on a future resolution being possible.

[Danno]

I've been meaning to post this for some time now, but the pandemic and other things in life sidetracked me. But, I made a bit of positive progress getting the controller to work with Spy Hunter and wanted to share some of the info (hopefully I'll remember things correctly!).

I found some info indicating that the lr-mame2003-plus emulator had better support for analog controllers than lr-mame2003, so I switched to use that:

Once in Emulationstation, I enabled the X-INPUT mode of the steering wheel, and it was detected as a "CHIPUNION USB RACING WHEEL"

Then, within the Retroarch configuration menus, there were now options for the axis configuration (+ and -) involved with the gas and brake pedals, and steering wheel (paddle):

I then tried playing a few games, and found the acceleration of Spy Hunter's car was a bit sluggish. I adjusted some of the sensitivity settings for the gas and brake pedals, and the steering wheel (paddle):

Though not perfect, it made the gameplay good enough that I got through the initial round of cars, got the oil and smoke defenses, and almost made it to what I think would have been the motorboat segment of the game.

If I make any other headway, with either Spy Hunter or other steering wheel games, I'll try to post back here with an update.