Discussion: `GlobalProductId`

[briaguya0]

First and foremost the idea of having a global identifier for devices is an awesome one. I also know it's not an entirely new idea, and I'd love to start a conversation about how to avoid some of the pitfalls that similar systems have encountered.

The project I'm most familiar with that has something similar is SDL (specifically https://github.com/mdqinc/SDL_GameControllerDB).

The main issue I've noticed there is controllers with different layouts that share USB VID/PID:

• Duplicated/conflicting GUIDs for the DragonRise/PC TWIN SHOCK controllers mdqinc/SDL_GameControllerDB#202
• Mayflash N64 Controller Adapter mdqinc/SDL_GameControllerDB#625

There has been some work done to use CRCs based on device names in SDL to reduce collisions (libsdl-org/SDL@3cbfd75, mdqinc/SDL_GameControllerDB#609), but this is not a foolproof solution.

One example where this solution was not viable is discussed in mdqinc/SDL_GameControllerDB#625, where a controller adapter packaged as a "Mayflash N64 Controller Adapter for PC USB" uses the same VID/PID (VID/PID: 0x0e8f/0x3013) and name ("HuiJia USB GamePad") as "HuiJia SNES". This means that there are 2 different devices with completely different sets of buttons/axes that result in identical SDL GUIDs.

I'm sure handling cases like this is an achievable goal for the GlobalProductId in this project, and I'm looking forward to hearing ideas people have! I'm certain with enough minds on this an elegant solution will be found!

[pastaq]

While we haven't quite started on the SDL implementation, the expectation is any "consumer" process that reads from a UCIS device in a compliant way will be able to get usage context from the device about each feature reported by the device. This should prevent issues with collisions like this as SDL will be able to parse the reports for specific features and then handle them without needing to rely on a VID/PID match for a button mapping. I.E. if someone created a UCIS HOTAS and a UCIS controller, each axis, button, etc. will be identified by use and SDL can bypass using a button mapping but still know what each button does.

As far as PID vs GPID, we added that as an early concept of how to solve this problem but haven't fully fleshed it out. The original concept had to do with getting a unique product ID for a UCIS compliant device that aggregated multiple input sources via a kernel driver or intermediary daemon like InputPlumber. A lot of these devices use Microsoft VID/PID for the primary gamepad, and we intended to pass the "Primary" VID/PID to the UCIS interface. GPID would allow SDL to identify an ROG Ally from an xb360 controller so that Steam could display a device specific image in steam input and acknowledge the extra inputs, as well as have matching button glyphs.