[IMPORTANT] Documented that input_vendor_id, and input_product_id are used by udev

[davidhedlund]

Description

Until this issue has been solved it will be impossible to duplicate files and modify the input_device, to make controllers compatible with linuxraw, or udev for with multiple Linux kernel versions, or BlueTooth/USB:

• [IMPORTANT feature request]: Support multiple input_device, input_device_display_name, input_vendor_id, and input_product_id variables #16907

In RetroArch, the linuxraw and udev drivers rely on input_device instead of input_vendor_id and input_product_id. These drivers automatically select the autoconfig file that matches the name used by the active Linux kernel.

However, when using udev, RetroArch still generates input_vendor_id and input_product_id, even though they aren't necessary. This behavior is not present in linuxraw. The issue with udev creates the impression that users need to comment or uncomment these IDs to choose which udev autoconfig file to use, especially when multiple autoconfig files are available—a common scenario for both non-HID and HID autoconfig files.

Expected behavior

The configuration should be as follows:

input_driver = "udev"
input_device = "Pro Controller"

Also, input_driver and input_device should not be required by PR checks for udev (they are not required by linuxraw)

Actual behavior

udev: The configuration currently includes unnecessary vendor and product IDs:

input_driver = "udev"
input_device = "Pro Controller"
input_vendor_id = "1406"
input_product_id = "8201"

linuxraw

input_driver = "linuxraw"
input_device = "Pro Controller"

Steps to reproduce the bug

• Change the controller profile directory.
• Navigate to Settings -> Drivers -> Controller, and select "udev".
• Restart RetroArch to apply the new setting.
• Go to Settings -> Input -> RetroPad Binds -> Port 1 Controls, and click on "Save Controller Profile".
• Repeat step 1-3 but select "linuxraw" in step 1

Todo list

After resolving the issue, please remove input_driver and input_device from the following autoconfig files that I am maintaining:

• DualSense
• Nintendo Switch Pro Controller
• Nintendo Switch Pro Controller (non-HID)
• DualShock 4 v2

Newly created PRs that can be used to diagnose this issue:

• [Ready for RetroArch 1.20.0] udev: Update Sony Interactive Entertainment DualSense Wireless Controller.cfg retroarch-joypad-autoconfig#1140
• [Ready for RetroArch 1.20.0] udev: Update and rename Nintendo Co., Ltd. Pro Controller.cfg to Nintendo Switch Pro Controller retroarch-joypad-autoconfig#1186

Version/Commit

• RetroArch: 1.19.1

[zoltanvb]

Hello,

I'd like to ask about this statement:
In RetroArch, the linuxraw and udev drivers rely on input_device instead of input_vendor_id and input_product_id.
Linuxraw driver has no way of retrieving vendor/product ID, as we have concluded under an earlier ticket. But udev seems to retrieve it and supply it for the autoconfig matching logic, so why would it be unnecessary?

RetroArch/input/drivers_joypad/udev_joypad.c

Line 211 in 585e70e

if (ioctl(fd, EVIOCGID, &inputid) >= 0)

and

RetroArch/input/drivers_joypad/udev_joypad.c

Line 279 in 585e70e

input_autoconfigure_connect(

[davidhedlund]

Hello,

I'd like to ask about this statement: In RetroArch, the linuxraw and udev drivers rely on input_device instead of input_vendor_id and input_product_id. Linuxraw driver has no way of retrieving vendor/product ID, as we have concluded under an earlier ticket. But udev seems to retrieve it and supply it for the autoconfig matching logic, so why would it be unnecessary?

RetroArch/input/drivers_joypad/udev_joypad.c

Line 211 in 585e70e

if (ioctl(fd, EVIOCGID, &inputid) >= 0)

and

RetroArch/input/drivers_joypad/udev_joypad.c

Line 279 in 585e70e

input_autoconfigure_connect(

Could you please review and confirm the following steps?

1. Generate an autoconfig file for the udev controller driver for your controller.
2. Remove input_vendor_id and input_product_id from the autoconfig file.
3. Restart RetroArch. Test the controller in: Main Menu -> Load Core -> Start Remote RetroPad.
4. It works, correct?
5. Modify input_device in the autoconfig file.
6. Repeat step 3.
7. It does not work, correct?

I am curious about what the code does in the lines you mentioned.

If input_vendor_id and input_product_id are essential, we should include this information in our joypad user guide by adding something like : The udev controller uses the input_device as well as input_vendor_id/input_product_id. input_device is used to identify and connect the controller, and the input_vendor_id and input_product_id variables are used for [arguments].

[zoltanvb]

Doing the above, I get the following with my controller:

• after step 1, I get the new autoconfig file (created by me) during connection
• after removing the input_vendor_id and input_product_id from the autoconfig file generated by me, I get another match (this is an XBox One pad, there is already a suitable autoconfig with same vid/pid, but slightly different name)
• if I remove the other autoconfig files, but keep the one generated by me, it will be found even with vendor and product ID removed

All in all, it works according to the affinity rules:

RetroArch/tasks/task_autodetect.c

Line 104 in 329b16d

/* Returns a value corresponding to the

[davidhedlund]

Doing the above, I get the following with my controller:

* after step 1, I get the new autoconfig file (created by me) during connection

* after removing the input_vendor_id and input_product_id from the autoconfig file generated by me, I get another match (this is an XBox One pad, there is already a suitable autoconfig with same vid/pid, but slightly different name)

* if I remove the other autoconfig files, but keep the one generated by me, it will be found even with vendor and product ID removed

All in all, it works according to the affinity rules:

RetroArch/tasks/task_autodetect.c

Line 104 in 329b16d

/* Returns a value corresponding to the

• Thank you for providing a helpful reference for our guide. I assume the same principles apply to the issue discussed at [IMPORTANT] Document that input_device is utilized by the android, and sdl2 controller drivers #16920. Could you please evaluate it, and post something there? I'll review these issues tomorrow and update our guide accordingly.

[davidhedlund]

• Documented: Update controller-autoconfiguration.md -- The android, udev, and sdl2 drivers can use either the Device Index (input_device) or a combination of Vendor ID (input_vendor_id) and Product ID (input_product_id) -- Thanks zoltanvb! docs#984

Thank you very much for taking the time to assist Zoltanvb!