2 controller issues that have popped up

RetroArch Windows devices
,
#1

Long time user first time poster. I haven’t run across any issues I haven’t been able to solve until these 2 issues popped up. I’m using 1.9.0 with everything updated on Windows 7 SP1.

  1. When I plug my RetroUSB RetroPort NES adapter in, “Retr (61140/3) not configured” pops up and the controller does not work. I have an old install of 1.7.8 and when I plug the adapter in it is recognized properly and the controller works fine. I replaced the 1.9.0 autoconfig directory with the one from 1.7.8 but it didn’t fix it the issue. I am using the dinput driver with xinput but have also tried dinput and that also does not work. I know I can configure it manually but autoconfig should be working since it has in the past. RetroUSB_RetroPort_NES.cfg is identicial between 1.7.8 and 1.9.0.

  2. I have Mayflash and RetroUSB NES, SNES, N64, and Genesis USB adapters. On older versions of Retroarch, when I plugged my controllers in the A and B buttons on all controllers worked as ok and cancel buttons. Now only one of the buttons on each controller works as cancel and I can’t figured out how to get an OK button configured. I’ve been forced to use enter on the keyboard to select.

Appreciate anyone pointing me in the right direction on these issues. Thanks!

1 Like
#2

Prior to 1.9.0, xinput and dinput drivers were enmeshed in such a way that sometimes autoconfiguration profiles would jump from one to the other in unexpected and often inconsistent ways. The changes make the behavior more predictable but also more strict, so a lot of controllers that were autoconfigured before (arguably erroneously).

With all of that said, you should be able to just configure the controller(s) and save a new autoconfig profile and, if you don’t mind, add the button labels and PR it to the repo (or just post it here and we can add it manually) for future inclusion.

#3

Ok I see what the issue is. I saved the autoconfig profile and it is exactly the same as what is in the autoconfig/xinput directory but it created it in the autoconfig/dinput directory.

I’ll try the other but wouldnt the fix just be to recreate the autoconfig files from the xinput directory and change the driver in the config file? There are far fewer files in the dinput directory.

As a side note, I cannot select xinput as the driver, the option isn’t available. I’m assuming that’s because I’m on Windows 7?

#4

Yes, a lot of the time just copying the autoconfig from one to the other and changing the driver ref in the config is enough to fix it. We don’t know if that will always work, though, as the aforementioned bad behavior was basically doing exactly that, so we want to actually confirm on a case-by-case basis.

Dunno about the win7 thing, but yeah, it’s possible.

2 Likes