_**Summary:**_ - changes hidraw handling for VID 3344 devices to a catch-all, ensuring the multitude (36+ devices) of virpil(vpc) devices with nearly infinitely variable parameters are all supported.
_**Reason for code departing existing standards:**_ - Virpil (vpc) devices all require hidraw, vpc has never expressed interest in making a device that does not, and the devices have user defined: button counts (0-128), axis counts (0-8), PID (mandatory for user to change in case of twin-stick or twin control panels), and device descriptions. default PID is dependant on revision of device or first-firmware-installed. Because of how custom each users device is, indexing them from anything apart from VID will inherently miss some(often many) devices, breaking support.
- Unfortunately, the cat is well and truly out of the bag already for virpil, so fixing the PID issues by way of virpil releasing firmware changes is not practical (forcing PID changes from virpil would reset keybinds for ~10k-100k windows and linux users in many of their games).
_**Possible (theoretical) flaw with the approach:**_ - Leaguer Microelectronics (LME) shares a VID with Virpil (VPC). If any devices exist outside of virpil (say, a bootleg xinput controller off aliexpress that chose a random vid and landed on 3344), they may be adversely affected and need explicit exemption else the end user would need to set them similarly to how virpil users need to modify their kit today. LME is primarily an IoT company so should not cause any issues, but it is possible. similarly, if VPC ever released a gamepad controller (xinput) it would also have issues. VPC has never expressed interest in doing this however, so this fix should be safe forever for VPC. LME being IoT should be fairly safe, but it is something to watch for.
_**The fix for the theoretical flaw:**_ - should this show up as a real issue, explicit exemption from this catch-all via an if-else or switch statement for adversely affected devices should be done.
_**Closing:**_ - If there are any questions / comments, I am happy to discuss it. After long thought, ~2 years of talk on proton issues, this seems to be the logical best solution for a fix given the specific situation. In the interest of keeping this some-what light reading for a laughably small code change, I will spare the minutia of the technical details for the hardware. Hopefully this merge request should provide adequate information to any maintainer looking at why this code is the way it is, some decade down the line.
Have a nice day.