but only the dpad/left analog stick.Īnother wrinkle is that if I start Retroarch with the PS3 controller plugged in, it black-screens and does not load the menu. I also tried the newest RA Wii but that didn't get me much further. My PS3 controller lights come on and start charging when I plug it into the wii, so I don't -think- it's a hardware issue. I tested both controllers on my computer, both are working fine. I tried unplugging and plugging in the controllers after the program had booted, no dice.
RETROLINK NES CONTROLLER RETROARCH.CFG DRIVER
Tried a retrolink/retro-bit generic Saturn pad, and a Dualshock 3, neither work when I reboot Retroarch after setting the joypad driver to hid.
I have input driver set to gx and joypad driver set to hid. Vendor ID: 121 - Product ID: 6 - Name: Generic USB JoystickĭragonRise_Inc._ Generic_USB_Joystick.cfg Duplicates inside 'xinput' folderĭragonRise_Inc._ Generic_USB_Joystick.I'm using RA 1.7.5 on my Wii. Gametel.cfg Duplicates inside 'dinput' folder Vendor ID: 9654 - Product ID: 1 - Name: Gametel Vendor ID: 2064 - Product ID: 58625 - Name: usb gamepad Generic USB JoystickĭragonRise_Inc._ Generic_USB_Joystick.cfgĭragonRise_X-Box_Gamepad_with_Force_Feedback.cfg Vendor ID: 121 - Product ID: 6 - Name: DragonRise Inc. Vendor ID: 3727 - Product ID: 12307 - Name: HuiJia USB GamePad Vendor ID: 121 - Product ID: 17 - Name: USB Gamepad 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 Let me know if you want some help to clean it up. 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 This is a list of duplicate profiles currently present in the repo. I think # 3 is the more "correct" one, but it's also the hardest one. Or potentially other firmware information that can help to clearly identify each different controller For example, number of buttons/axes reported by the device. Modifying Retroarch to use more attributes from the controller to match the right profile.Some documentation about that may be useful so people understand what's happening Then, other users with conflicting controllers will need to create their own profiles to be used locally in their environments. Randomly choosing which one is selected to be offered as the "useful default".
Some documentation around this scenario could be useful Every user with a "generic" controller will have to define their own profiles locally. Removing all profiles for the affected "generic" controllers.I think we should do one of these things:
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 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 kommentar(er)
