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. IMHO removing "variables" (any attribute describing the controller) won't help at all. 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. So removing vendor and product id will leave us with two matching profiles with the same name. In this case, the two autoconfig profiles match exactly in the three attributes. I think that won't fix the issue I understand correctly, Retroarch uses input_device, input_vendor_id and input_product_id attributes to match controllers. 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.Īn easy workaround for people having this issue is to remove in their own environments the autoconfig file that creates the conflict. 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). Retroarch uses three gamepad attributes to uniquely identify the controller but that is not enough. It may be that some cheap generic circuits are being used for completely different layouts, so there's a naming colision 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. I have an alternative (not original) PS3 controller that also has a conflict with these other two examples you mentioned here. I know this issue is old, but this comment help other people reading this issue.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |