Retroarch still cant differentiate between Xbox Controllers

[Yasaka7]

Is there an existing issue for this?

• [x] This is a bug in RetroArch frontend
• [x] I have searched the existing issues

Description

So i have an 8bitdo controller which uses xinput and works fine without changing anything in the button layout. But i also have a gamecube controller and i use delfinovin to emulate an xbox controller so i can use my gamecube controller in retroarch, games etc. However the layout is a different one so i need to map every button manually. when i save the config, it saves the config for an xbox 360 controller. however the 8bitdo is also detected as an xbox 360 controller.

The problem: when retroarch saves the config it always saves it for ANY xbox360 controller since the configs name is xbox 360. so i have to remap my controller everytime i change the controller. This is a problem for years now and my workaround is that i just use 2 completely different retroarch instances so i can save my button layout.

Please implement that you can actually name the cfg file yourself and that you can choose which cfg file to load for which controller or change the way Controllers are detected.

Expected behavior

Retroarch should detect Controller differently so even if both are detected as XBOX 360 controller Retroarch can still differentiate between those.

Steps to reproduce the bug

1. Have to different controllers with different internal button mapping that your computer detects as XBOX 360 controller.
2. Try saving the correct button layout for each one.
3. Since for Retroarch they are the same it will overwrite the same cfg file for both controllers and you have to remap the other controller again in order to use it.

Version/Commit

1.20.0

Bisect Results

No response

Present in the nightly version

I don't know

Platform & operating system

Windows 10

Affected Cores

No response

Environment information

No response

Relevant log output

[hizzlekizzle]

How are we supposed to tell them apart if they're both giving us exactly the same (false) information?

[Yasaka7]

How are we supposed to tell them apart if they're both giving us exactly the same (false) information?

Like mentioned, if this isnt possible it would be really useful if one could name the cfg file when its saved, and actually be able to load a certain cfg file. because right now you cant even load a cfg. you only can save one and its loaded automatically.

[cmitu]

It's possible if you change the joypad profiles' path (option: joypad_autoconfig_dir), which you can set in a separate .cfg with --appendconfig.

Another option would be to configure (if possible) the remapping software (delfinovin ?) to use a different name or Vendor/Product IDs for the emulated Xbox controller. RetroArch can use also the Vendor/Product IDs to differentiate between 2 controllers that have the same name and load their corresponding profiles.

[YutMarma]

How are we supposed to tell them apart if they're both giving us exactly the same (false) information?

I don't have much under-the-hood experience, so forgive me if this is completely idiotic, but you could probably use Container Id, assuming that's a value that's exposed to RetroArch.

I own both a Pro 2 and a SN30 Pro. The Pro 2 also reports 557d57e9-b8aa-5c4c-bd47-5d26ef7ea5e6 as its Container Id, whereas the SN30 Pro is e266c8d4-38f4-11f0-967d-047c1671dc1e. These may change from machine to machine - not sure - but what matters is that on my machine, the Pro 2 is always --ea5e6, and the SN30 Pro is always --1dc1e, regardless of which port they're plugged into, and this value is persistent through reboots.

If that's something that Windows is willing to pass on to RetroArch, it seems it'd be pretty simple to create a GUID of some sort and then append that GUID to its .cfg names. Then even if we end up with "Controller (XBOX 360 For Windows) hash-gibberish.cfg" and "Controller (XBOX 360 For Windows) different-hash-gibberish.cfg, at least RetroArch itself would be able to figure out which applies to which.

Definitely preferable to having to use dinput, since (at least on the 8BitDo) some features are only available in xinput mode. Also, in dinput, it creates the L2/R2 triggers as buttons rather than an axis, which means even the slightest touch will set them off (on the Pro 2, at least - on the SN30, they're just buttons with extra travel).

[cmitu]

I don't have much under-the-hood experience, so forgive me if this is completely idiotic, but you could probably use Container Id, assuming that's a value that's exposed to RetroArch.

What is a Container Id ?

[YutMarma]

I don't have much under-the-hood experience, so forgive me if this is completely idiotic, but you could probably use Container Id, assuming that's a value that's exposed to RetroArch.

What is a Container Id ?

Here's the official Microsoft documentation on it. From a brief skim, it does in fact appear to be an OS-assigned unique (and, importantly, persistent) ID for each peripheral.

So, Container Id (which is how it's capitalized in Control Panel > Device Manager > Details) is only a Windows thing, but since xinput is pretty much also only a Windows thing, it's sort of a match made in heaven. Linux might also have something similar with a different name, but my brief search turned up way too much Docker-container-related spam to sift through :)

[cmitu]

Here's the official Microsoft documentation on it. From a brief skim, it does in fact appear to be an OS-assigned unique (and, importantly, persistent) ID for each peripheral.

Doesn't this mean that a 2nd identical controller will get a different ID, even if it's the same model ?

[YutMarma]

Doesn't this mean that a 2nd identical controller will get a different ID, even if it's the same model ?

I suspect so, though I haven't yet confirmed. Just ordered a pair of cheapo controllers, I'll be able to confirm tomorrow.

I also believe the Container IDs may be unique per computer - e.g., if I went over to your house and plugged my Pro 2 in, it might end up with a Container ID of 56bd4331-bac4-662c-4732-99c6e7c5512b. Will confirm later today.

Either way though, I don't think this is too much of an issue - worst-case, people with a pair of controllers would have to configure each of them separately. RetroArch could still use reported name as a generic starting point - so just like how Game Overrides supercede Content Directory Overrides, a ControllerName_ContainerID .cfg could supercede a ControllerName-only .cfg, so default controller .cfgs could still be distributed (and then be automatically turned into personalized ControllerName_ContainerID cfgs when RetroArch first sees them).

[YutMarma]

Doesn't this mean that a 2nd identical controller will get a different ID, even if it's the same model ?

So, two days and one cheapo pair of SNES-style controllers off Amazon later:

1. As I suspected, the Container ID is unique-per-computer. On a second computer, the Container ID of the same SN30 Pro was 73ca6f1c-3c09-11f0-8987-ecb1d75866d2.
2. However, on a given computer, the Container ID will be the same for different identical controllers of the same model. So you could have 100 people, each with their own individual controller, and as long as they were all the same model, you'd only need one .cfg file. In this case, both cheapo SNES-style controllers (which will soon be donated to a thrift store) are {731944cb-3e6d-11f0-967e-047c1671dc1e} - interesting how close this is to the SN30 Pro, 19 of the last 20 bytes are identical:

{e266c8d4-38f4-11f0-967d-047c1671dc1e} (SN30 Pro) {731944cb-3e6d-11f0-967e-047c1671dc1e} (Cheapo SNES-style)

So, anyway, based on these findings, it seems to me that the best process for RetroArch would be:

1. Look for a .cfg that matches the device name, same as current behavior. If found, apply it. This allows for centralized controller-preset distribution, whether it's from the internal downloader or someone sharing their own .cfg on a forum.
2. Look for a .cfg that matches the device name and Container ID (or a GUID that uses the Container ID as a seed value - probably better to use a derived GUID, since the Container ID is lengthy!). If found, apply it on top of what's already been loaded. Similar to game overrides loading on top of core overrides, which load on top of regular settings; except here it's the Name-GUID.cfg on top of the plain Name.cfg. Technically, it could just be GUID.cfg, but I think keeping the name in the filename as well is good for human readability.
3. If no Name-GUID.cfg is found, automatically create one, using the current settings loaded from the Name.cfg. All modifications to the controller cfg should be saved by default to Name-GUID.cfg, though a menu setting could exist for people to save to a plain Name.cfg file, to make swapping between computers easier.
4. Of course, people can always manually load any .cfg they want, even if it's a non-matching Name/GUID. This way, if I'm installing RetroArch on a new computer, I can just copy my old .cfgs over and use them, even if I forgot to enable the "Save Updated Settings to Plain Name.cfg File" option described above. RetroArch would then automatically create an updated Name-GUID.cfg with the new computer-specific GUID.

Thoughts?

[cmitu]

As I suspected, the Container ID is unique-per-computer. On a second computer, the Container ID of the same SN30 Pro was 73ca6f1c-3c09-11f0-8987-ecb1d75866d2.

This means the user needs to create/add their own auto-configuration profile on the system where they run RetroArch, which would override (one of) the distributed joypad auto-configuration profiles.

Not sure if it's worth adding this to the xinput (maybe also dinput ?) driver.

[YutMarma]

This means the user needs to create/add their own auto-configuration profile on the system where they run RetroArch, which would override (one of) the distributed joypad auto-configuration profiles.

Did you read my whole post, though? I specifically addressed that exact concern.

The user doesn't have to do anything manually, either - RetroArch can absolutely take care of this behind-the-scenes.

Not sure if it's worth adding this to the xinput (maybe also dinput ?) driver.

Considering a significant feature of RetroArch is essentially broken with the current system, I would politely suggest otherwise.

It may not be RetroArch's fault that some manufacturers name their devices in dumb ways, but it's up to RetroArch to account for it.

[cmitu]

Did you read my whole post, though? I specifically addressed that exact concern.

The user doesn't have to do anything manually, either - RetroArch can absolutely take care of this behind-the-scenes.

In any situation, since the GUID is locally generated, the users' action is required - either facilitated through a RetroArch menu or not. I call this a manual action as opposed to the auto configuration profiles distributed with RetroArch and are used to configure the controller.

Considering a significant feature of RetroArch is essentially broken with the current system, I would politely suggest otherwise.

Which feature are you referring to ? Do note that I'm not a RetroArch/libretro dev, just a regular user and - as they say - opionions are my own.

[gouchi]

Similar older issue.

[YutMarma]

In any situation, since the GUID is locally generated, the users' action is required - either facilitated through a RetroArch menu or not. I call this a manual action as opposed to the auto configuration profiles distributed with RetroArch and are used to configure the controller.

Ah, I gotcha. Well, by that definition, I agree - but no more manually-generated than generating an .xml when scanning a content directory. It'd also be very similar to how RetroArch handled the data format change when it adopted JSON - load the old file, convert to new format behind the scenes, save new format automatically.

To me, "manually-generated" means more like creating/editing .cfgs in a text editor, so that's why I was confused.

Which feature are you referring to ?

Oh, in case it wasn't clear, I'm referring to the original issue, the one that's been described throughout this thread. Not what you posted on January 28th.