Conflicting configs DragonRise and Retrolink_N64

[alfrix]

On both dinput and xinput

1. DragonRise_Inc.GenericUSBJoystick
2. Retrolink_N64_USB

Have the same name VID and PID:

input_device = "Generic   USB  Joystick  "
input_vendor_id = "121"
input_product_id = "6"

The config files are very different, which means the gamepads are not the same.

Since RetroArch applies the last file name (in this case Retrolink_N64.cfg) as a workaround for DragonRise i have renamed the file as Z.cfg

[MatiasFernandez]

I know this issue is old, but this comment help other people reading this issue. I have an alternative (not original) PS3 controller that also has a conflict with these other two examples you mentioned here.

My guess is that some generic controllers report themselves to the OS using a vendor ID, product ID and input device name that is pretty generic. It may be that some cheap generic circuits are being used for completely different layouts, so there's a naming colision here.

Retroarch uses three gamepad attributes to uniquely identify the controller but that is not enough. It will be great to have a way to remove the ambiguity by a setting in the UU (manual interaction) or maybe using other controller details to improve the matching process (like number of buttons and axes).

I don't think the devs are super interested in doing something like this due to the low presence of such generic controllers within retroarch's user base.

An easy workaround for people having this issue is to remove in their own environments the autoconfig file that creates the conflict.

[offalynne]

It'd definitely be better to remove this VID/PID from autoconfig altogether. There are at least a dozen devices that use the chip, all of them have different layouts. To date there's no obvious pick between them based on market share, device type or button layout. As such, identifying them with the existing system is most likely to produce an incorrect mapping.

[offalynne]

See also https://github.com/gabomdq/SDL_GameControllerDB/issues/202

[hizzlekizzle]

How would you guys feel about me commenting the VID/PID on all of these and letting it match on just the name?

[offalynne]

That would certainly be for the best. Far as I can tell they all share the name ‘DragonRise Inc. PC TWIN SHOCK Gamepad’, so ID by name is likely to fail as well.

[MatiasFernandez]

I think that won't fix the issue @hizzlekizzle

If I understand correctly, Retroarch uses input_device, input_vendor_id and input_product_id attributes to match controllers. In this case, the two autoconfig profiles match exactly in the three attributes. So removing vendor and product id will leave us with two matching profiles with the same name.

I think the only way to fix the underlying issue is to introduce an additional "variable" that allow us to uniquely identify the right controller. IMHO removing "variables" (any attribute describing the controller) won't help at all.

I think Retroarch currently has a limitation of just working "as expected" when just one autoconfig profile for a combination of input_device, input_vendor_id and input_product_id exists. If somebody has a controller with a different layout but the same input_device, input_vendor_id and input_product_id they basically won't have a way to share that mapping to other people because Retroarch can't differentiate between all the profiles that are "equal".

I think we should do one of these things:

1. Removing all profiles for the affected "generic" controllers. Every user with a "generic" controller will have to define their own profiles locally. Some documentation around this scenario could be useful
2. Removing all profiles but one. Randomly choosing which one is selected to be offered as the "useful default". Then, other users with conflicting controllers will need to create their own profiles to be used locally in their environments. Some documentation about that may be useful so people understand what's happening
3. Modifying Retroarch to use more attributes from the controller to match the right profile. For example, number of buttons/axes reported by the device. Or potentially other firmware information that can help to clearly identify each different controller

I think # 3 is the more "correct" one, but it's also the hardest one. So I vote for # 2, because that one is easier to maintain through time with the easy "rule" of not accepting duplicate profiles in the repo

[offalynne]

Removing all profiles for the affected "generic" controllers.

This best fits the goals of the project. If the device can not reliably be auto-configured than it should be left to manual configuration. Until such a time that the format supports a field to reliably differentiate them, they should be stubbed or removed altogether.

[hizzlekizzle]

ok, what I can do is comment all three fields on all but one and if we figure out some way to disambiguate them in the future, I'll just remove the comments.

[MatiasFernandez]

@hizzlekizzle This is a list of duplicate profiles currently present in the repo. Let me know if you want some help to clean it up. If we define a clear criteria I can prepare a PR (e.g: keep the one that was added first or maybe keep the one that appears last in the file list because I think that's the one that is actually being used currently)

Duplicates inside 'udev' folder

Vendor ID: 121 - Product ID: 17 - Name: USB Gamepad DragonRise Inc. Gamepad.cfg Retrolink_Sega_Saturn_USB_GamePad.cfg USBGamepad.cfg

Vendor ID: 3727 - Product ID: 12307 - Name: HuiJia USB GamePad HuiJia USB GamePad.cfg Mayflash_N64_to_USB_Adapter.cfg

Vendor ID: 121 - Product ID: 6 - Name: DragonRise Inc. Generic USB Joystick DragonRise_Inc.GenericUSBJoystick.cfg DragonRise_X-Box_Gamepad_with_Force_Feedback.cfg DragonRise_N64.cfg DIALOG_GP-A11.cfg

Vendor ID: 2064 - Product ID: 58625 - Name: usb gamepad usb_gamepad___(PS1).cfg usb_gamepad___(SNES).cfg usb_gamepad___(NES).cfg usb_gamepad___(SEGA).cfg

Vendor ID: 9654 - Product ID: 1 - Name: Gametel Gametel_Bluetooth_controller.cfg Gametel.cfg

Duplicates inside 'dinput' folder

Vendor ID: 121 - Product ID: 6 - Name: Generic USB Joystick Retrolink_N64_USB.cfg DragonRise_Inc.GenericUSBJoystick.cfg

Duplicates inside 'xinput' folder

Vendor ID: 121 - Product ID: 6 - Name: Generic USB Joystick Retrolink_N64_USB.cfg DragonRise_Inc.GenericUSBJoystick.cfg

Duplicates inside 'android'

Vendor ID: empty - Product ID: empty - Name: PlayStation3 DualShock3.cfg GPD_Q9.cfg

Vendor ID: empty - Product ID: empty - Name: USB Gamepad Trust_Predator.cfg Defender_Game_Racer_Classic.cfg

[hizzlekizzle]

Let's do: Retrolink_Sega_Saturn_USB_GamePad.cfg Mayflash_N64_to_USB_Adapter.cfg DragonRise_N64.cfg usb_gamepad___(PS1).cfg Gametel.cfg Retrolink_N64_USB.cfg DualShock3.cfg and your choice on the last one (i.e., Trust_Predator or Defender_Game_Racer_Classic) :)

I picked ones that had a specific layout implied by the name, so if someone has a different pad, it should be readily apparent that it's a false match (instead of, say, just a bad/weird choice of mapping).

[MatiasFernandez]

This is fixed. We can close it