Autoconfig mis-identification

Coming back to this issue in some time. I just installed a fresh copy of Retroarch x64 and my n30 modkit (BT) is now being read as the F30 Arcade. I renamed the F30 BT file in the autoconfig dinput folder and that did prevent the modkit from being read as the F30, but Retroarch seems to be traversing and identifying every single BT file in dinput except the correct n30 modkit BT file. I keep renaming files as they pop up in Retroarch, but not sure when it’ll get to my device. I crosschecked vendor and product IDs in Device Manager and, if I’m reading the hex codes right, the numbers in the correct autoconfig file are, in fact, correct.

Any next steps for troubleshooting? Should I switch the BT controller over to another mode like xinput or something (I forget which was which, but possible 8bitdo’s “android” mode corresponds to dinput?).

Steps I’ve taken to try and solve this so far:

  • Removed all other 8bitdo devices from Windows
  • Put the controller in xinput mode and paired (it just turns into an XBox controller)
  • Put the controller back in dinput mode and paired (Windows detected it correctly)
  • Researched and found out how to update the controller’s firmware (there’s a micro USB port on the PCB, but you have to extract it from the shell)
  • Backed up autoconfig files one by one as Retroarch tried to read them as the device ID

Notes:

  • I am on Windows 11, latest non-Insider release
  • Vendor ID as read from Device Manager: BTHENUM\Dev_E417D80F627D (after updating the controller firmware, I can’t find device or product IDs separately… some kind of artifact of the update?)
  • Enabled Verbose Logging, but only see the device read as “dinput” without printing device or product IDs.

That’s where I’m at on this so far. I guess something’s changed in how the device ID is reported or how Retroarch reads them in. I’m trying to figure out what the modkit’s ID is, but have forgotten how to parse the above hex information.

I think Android mode is usually the one that does the best job of reporting what it actually is vs lying about it for compatibility purposes.

So I actually am in Android mode, which I thought reported as ‘dinput’, no? At least every time I’ve connected my controller, the log window reports it as dinput. Just as a sanity check, the modkit manual instructions say:

Android

  1. "Press START +B to turn on the controller, LED will blink once per cycle.

That’s the hardware mode I’m using and pairing for sure. I tried turning on every logging setting I could find in the UI or in the config, but Retroarch just keeps reporting ‘dinput’. No IDs.

that sounds like you’re doing the right pairing mode, then. Have you tried just deleting all of the autoconfigs and then making your own?

Funny you say that. I moved all the autoconfig files to a backup folder, leaving the modkit file. It does identify the controller as modkit, so I’m assuming what’s happening is that it’s traversing the files in some kind of fallback mode. I’d be fine editing the autoconfig file with the Windows VID and PID, but there are other controllers I’d like to use (other 8bitdo products and the SNES modkit, for example). So I need to verify somehow that Retroarch is correctly detecting the device itself and not just reverting to the file in whatever fallback mode it’s using.

I hope that makes sense. Feels like I’m close, but I don’t know what Retroarch is seeing in terms of VID and PID. Just that it’s a dinput device.

(thanks for your time btw; I know I come in here every year or so and have to recall how the config system and BTLE works… not dealing with it day in day out)

it should have the vid/pid in the widget that pops up identifying the pad, IIRC.

No, in-app it just pops up with the English friendly name regardless of verbose setting, in this case “8bitdo F30 Arcade”. Did I miss a setting somewhere?

Huh. Minor update. I have two modkits for reach controller type and the other N30 modkit with older firmware mis-identifies as an F30 Arcade device. The SN30 modkit for the Super Nintendo correctly identifies and is usable. It’s just the NES bluetooth modkit that’s having issues. Interesting.

Edit: looking at the SN30 modkit file, the product ID (in decimal) is 20739. That’s one off from the N30 of “20740” (reported in the Windows device properties as “04 51” in little endian) that I cross checked manually. I’m beginning to get more certain that the N30 numbers are correct. I’m not wanting to be presumptuous but the vague feelings of “bug-ishness” is increasing. Happy to run any other alternatives to ground.

Also, I don’t know where the config file’s default ID of “736” is coming from. Another mode somewhere that made it through a pull request?

1 Like

Belay my comments. The default autoconfig for this device is wrong, but my debugging skills are wrongerer.

I mistakenly entered “vendor_ID” twice where I corrected the product_ID. The correct identification for the N30 modkit should be:

# Hex vid:pid and Decimal vid:pid is shown in the "log_verbosity" window, enable "log_verbosity" in retroarch.cfg and run RetroArch.
# Hex vid:pid = 2DC8:5104 -> Decimal vid:pid = 11720:20740
# Aligning with SN30_Modkit in Android mode
input_vendor_id = "11720"
input_product_id = "20740"

The incorrect product id is “736” for some reason. That shouldn’t be there. The corrected PID is 20740. The Android comment is my personal editorial.

Since I’m not on here regularly, what repo should I be going to in order to make a pull request to change the PID?

1 Like

that would be https://github.com/libretro/retroarch-joypad-autoconfig

We appreciate it!

1 Like