New controller detected by Emulationstation but not working in Retroarch

Danno

I've spent a week now working on this issue, and have found a few threads mentioning some similar symptoms, but nothing I've come across has helped resolve the issue. So, here goes....

Gaming rig specs:

PC running Linux Mint 19.3, kernel 5.4.0-64-generic.
Retropie updated to 4.7.1 (Emulationstation 2.9.6 RP, Retroarch 1.8.8)
Main controller: Recroommasters Xtension Emulator Edition Plus, configured in 'keyboard' mode

The above system has been running solidly for me for well over a year now. Recently, I purchased an unbranded steering wheel controller (USB) that I plan to use for several driving games, including Spy Hunter. After plugging in the controller, I was able to configure it using Emulationstation, which detected it as an "Xbox 360 Controller". However, after launching Spy Hunter with the LR-MAME2003 emulator, a warning box pops-up at the bottom stating:
Microsoft X-Box 360 pad (1118/654) not configured.

That seemed weird, but I went ahead and opened the "quick" menu (using Tab key) to try and remap the game keys. However, none of the buttons on the steering wheel controller are being recognized. I tried going into the Retroarch menu under Settings - Input - User 1 Bind / Hotkey Binds, but had the same problem.

Here are things that I've tried so far:

Used the Joystick test program, JSTEST, using /dev/input/js0, and all inputs from the steering wheel controller (buttons, triggers, axis movement) register successfully.
Reconfigured the controller a few more times in Emulationstation, and reviewed the files at /opt/retropie/configs/all/retroarch-joypads/ and /opt/retropie/configs/all/emulationstation/,
which appear correct as far as I can determine.
Using Retropie-Setup - Manage Packages - Driver, installed "xpad" (and rebooted), and installed "xboxdrv" (and rebooted).
Tried using Advancemame (ver 3.9) but encountered essentially the same problem. A few times, after pressing several buttons in succession on the new controller, it seemed like Advmame captured
a few of them and showed them for the new mapping briefly, but then the entry blanked out quickly afterward. Not sure what to make of that, but seems to further indicate the controller is not fully being detected properly.
Enabled verbose logging when launching the game (LR-MAME2003), but didn't see any errors in the runcomaand.log. Here are some of the more relevant lines:

[INFO] [udev]: Hotplug add: /dev/input/js0.
[INFO] [udev]: Hotplug add: /dev/input/event22.
[INFO] [udev]: Plugged pad: Microsoft X-Box 360 pad (1118:654) on port #0.
[INFO] [udev]: Pad #0 (/dev/input/event22) supports force feedback.
[INFO] [udev]: Pad #0 (/dev/input/event22) supports 16 force feedback effects.

(The steering wheel has a vibrate mode, which I don't really care much about, that I assume is the 'force feedback' being mentioned).

I'm hopeful someone may have some advice regarding next steps. Any suggestions?

mitu

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

"Xbox 360 Controller".

That's not the same as 'Microsoft X-Box 360 pad'. Can you remove xboxdrv, reboot, then post the results of cat /proc/bus/input/devices and the whole RetroArch's log (on pastebin.com) ?

Danno

@mitu Thanks for replying. I figured the xpad/xboxdrv drivers probably wouldn't help since ES detected the controller fine without them, but thought they were worth a try. I removed xboxdrv and rebooted...output for the CAT 'Devices' command is here.

I quickly created a verbose log again running Spy Hunter under LR-MAME2003, and that log is here. Controller is showing as /dev/input/event22, but the 'Devices' output seems to skip from event21 to event23. Hope this helps move things forward.

EDIT: Forgot to previously mention one other thing I tried...used Retropie_Setup to test changing the Libretro configuration ("Configure basic libretro emulator options") to set the controller as the first/only entry under "Choose joypad order", but that didn't seem to have any effect.

mitu

xpad is the driver that's usually installed by default in RetroPie and it handles Xbox 360 (and compatible) gamepads. xboxdrv is not a driver, but simulates a virtual Xbox gamepad for compatible applications.

From your posts, I don't see an entry for the Xbox 360 pad in the devices listed. There's no /dev/input/event22 in the cat output. Are you sure xboxdrv is not running anymore ?

Danno

I read at the Retropie web site that starting with v 4.1, the xpad driver is enabled by default (not sure if that's only in Raspberry Pi images?), but it wasn't showing enabled in the setup script. I installed it from source, and did not remove that...only the xboxdrv 'driver' (followed by a reboot). I tried to look in /etc/rc.local to see if the startup config was removed but don't see that file at all.

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

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):
Screenshot from 2021-01-27 16-11-17.png

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:
Screenshot from 2021-04-05 12-20-40.png

Once in Emulationstation, I enabled the X-INPUT mode of the steering wheel, and it was detected as a "CHIPUNION USB RACING WHEEL"
Screenshot from 2021-04-05 12-39-15.png

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):
Screenshot from 2021-04-04 15-38-25.png

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):
Screenshot from 2021-04-04 15-39-42.png

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.