_**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.
From: "Ty (Chaos)" dc3120@gmail.com
--- dlls/winebus.sys/main.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c index cb9104ba056..71af8c0351f 100644 --- a/dlls/winebus.sys/main.c +++ b/dlls/winebus.sys/main.c @@ -474,13 +474,10 @@ static BOOL is_hidraw_enabled(WORD vid, WORD pid, const USAGE_AND_PAGE *usages, if (pid == 0x0127) prefer_hidraw = TRUE; /* VKB-Sim Space Gunfighter L */ break; case 0x3344: - /* comes with 31 buttons in the default configuration, or 128 max */ - if ((buttons == 31) || (buttons == 128)) prefer_hidraw = TRUE; - /* users may have configured button limits, usually 32/50/64 */ - if ((buttons == 32) || (buttons == 50) || (buttons == 64)) prefer_hidraw = TRUE; - /* if customized, arbitrary amount of buttons may be shown, decide by PID */ - if (pid == 0x412f) prefer_hidraw = TRUE; /* Virpil Constellation ALPHA-R */ - if (pid == 0x812c) prefer_hidraw = TRUE; /* Virpil Constellation ALPHA-L */ + /* all VPC devices require hidraw, have variable numbers of axis/buttons, & in many cases + * have functionally random PID. due to this, the only safe way to grab all VPC devices is + * a catch-all on VID and exclude any hypothetical future device that wants hidraw=false */ + prefer_hidraw = TRUE; break; case 0x03eb: /* users may have configured button limits, usually 32/50/64 */
Thanks, this looks alright. However the Wine Project requires every contributor to use their real first + last name in the commit author information. Let me know if this is an issue for you.
On Wed Jul 30 13:59:25 2025 +0000, Rémi Bernon wrote:
Thanks, this looks alright. However the Wine Project requires every contributor to use their real first + last name in the commit author information. Let me know if this is an issue for you.
it is, and I have requested an exemption in my user verification that Alexandre Julliard has approved, though he did not specifically comment on that request when approving it. (issue 105, marked as confidential). Happy to use first name, not so for the last name. Thanks
This merge request was closed by Rémi Bernon.
Closing as merged, thanks for your contribution!