On 7/30/20 11:54 PM, Swyter wrote: > On 31/07/2020 8:33, Cameron Gutman wrote: >>> While doing my research I also noticed that the 1532:0037 VID/PID seems to >>> be used by the DeathAdder 2013, so that Razer Sabertooth instance looks >>> wrong and very suspect to me, I created a separate patch for that. >> >> The above sentence probably doesn't belong in the commit message. >> > > Fair enough, I should probably turn that into "reviewer" notes. > I think I mentioned it because I didn't update that bad entry. > > Thinking it would be deleted soon. But good point. > > >> The docs and comment changes look fine to me. > > Great, I was a bit wary about this. > > >> I'm somewhat concerned about the possibility of breaking userspace by changing >> names. Some programs' gamepad mappings may be dependent on matching the device >> names, rather than the VID+PID. >> >> For example, Android did not expose the VID and PID for input devices until >> Android 4.4. The device name was the only available attribute for matching >> gamepads from Android 2.3 to 4.3. While these ancient Android version will >> almost certainly never run a kernel with this patch, I worry about the >> possibility of apps that haven't moved to VID+PID matching (and not just for >> Android; I don't know if other libraries or frameworks have/had similar >> limitations). >> >> Perhaps my concerns are overblown, but If we aren't worried about changing >> names, I'd really prefer to just drop the hardcoded names entirely and use the >> manufacturer and product strings provided in the USB string descriptors. The >> device list would turn into a quirk list where only device entries with a >> special mapping flag like MAP_DPAD_TO_BUTTONS or MAP_TRIGGERS_TO_BUTTONS would >> remain, and the device name strings would just become comments on each quirk >> entry. >> >> Thoughts? >> >> >> >> >> Regards, >> Cameron >> > > I don't doubt that changing some names will break some basic rule matching. > > But given that the kernel nomenclature is so inconsistent, I think anyone searching > for "X-Box" and five other variants will also have to search for the actual "Xbox", > or at least I hope so. Keep in mind that I have tried to make each overhauled entry > *more* detailed when possible. So now each model has extra information (mainly > manufacturer and button-layout type) instead only some vague/informal model name. > > SDL2 and Unity abstract these things a bit. I actually implement similar strings > checks in my own game/engine as fallback and it's exactly what I ended up doing. > > I generally don't trust device strings, they'll be less detailed than these. > A good bunch of those are unlicensed, so they'll be wrong or missing. > > Let me know what you think. > I agree that the changes look like an improvement. I also doubt that we'll ever be able to prove definitively that there aren't programs out that taking a dependency on the exact names of the gamepads in the list. I guess one could also make the argument that adding a gamepad to this list would have the same effect of possibly breaking userspace programs that used to identify it via the "Generic X-box Pad" string. Those programs would need to have the flexibility to handle receiving the generic name or a specific name from our list, so maybe they're already robust enough to handle not matching on one of the names they're expecting. Dmitry, what are your thoughts about possible userspace breakage from updating input device names? Has a similar change been done successfully before? Regards, Cameron
