Support VKB Gladiator NXT EVO and Virpil Constellation

[kakra]

These devices ship with 128 buttons by default. For game compatibility, the VKB Windows app can be used to change the HID descriptor to show only 32 buttons and have up to 4 virtual devices instead. These devices can also show up as a mouse or keyboard and send proper HID events for that configuration - not tested with this commit.

The Linux input layer gets really confused by these devices as the HID descriptor spans multiple ranges of different device type event codes. Hopefully, winebus.sys hidraw mode can work around this. Also needs udev rules to enable hidraw access.

Device info maybe relevant for implementation:

• has a programmable mini computer (32-bit ARM) which generates USB HID reports
• can be programmed to act as a mouse or keyboard, too
• consists of a base module and module extensions which are mountable grips
• can generate events for up to 128 buttons (through various shift and macro operations)
• can generate events for up to 16 axes (twice the amount of ordinary joystick devices)
• can generate events for up to 4 hats (8-way, usually, joysticks support just one 4-way hat)
• can be split into up to four virtual devices which split 128 buttons into 32 buttons each for better compatibility

Known limits:

• Elite Dangerous: 32 buttons
• Star Citizen: 50 buttons
• some other games: 64 buttons

Todo:

• Figure out why Elite Dangerous still sees a single gamepad -> needs registry cleanup, see below
• Figure out how to clean the registry from broken xinput driver links
• Test if other games properly see the joysticks
• Ask if we should mention somewhere to split the HID descriptor into 4 virtual devices

Without this patch, it's currently the same as running with PROTON_ENABLE_HIDRAW=0x23D1/0x0200,0x23D1/0x0201.

Notes

There's a hint about games seeing a gamepad with other HOTAS, too:

• Virpil controller support Proton#6839 - but SDL should be bypassed with hidraw
• https://www.reddit.com/user/xatrekak/comments/12hnz0d/fixing_vkb_and_virpil_hotas_running_on_linux/
• 0084:trace:hid:udev_add_device hidraw "/dev/hidraw6": deferring {vid 231d, pid 0200, version 2122, input 0, uid 00000000, is_gamepad 0} to a different backend
• maybe needs auto-correction of registry after switching to hidraw if the device was detected as xinput before?

The Windows software supports creating a registry patch which adds these entries:

Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USER\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\Vid_231D&Pid_0200]
[-HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\Vid_231D&Pid_0200]
[-HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaResources\Joystick\DINPUT.DLL\JoystickSettings\Vid_231D&Pid_0200]
[-HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaResources\Joystick\DINPUT.DLL\CurrentJoystickSettings]
[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\Vid_231D&Pid_0200]
[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\HID\Vid_231D&Pid_0200]
[-HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USB\Vid_231D&Pid_0200]
[-HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\HID\Vid_231D&Pid_0200]

But this looks like just creating empty nodes. Edit: It seems that this actually deletes contents from the nodes.

Wine adds registry entries linking the device to winebus driver but also to xinput:

• example: System\\CurrentControlSet\\Enum\\WINEBUS\\VID_231D&PID_0201 (vid/pid exists lower and upper case in the registry)
• removing those references from system.reg properly links the joystick to the HID driver next time the game starts

[kisak-valve]

Hello @kakra, I'm not particularly familiar with this corner of Proton's wine build.

Please add a note why this needs to be added downstream instead of in the upstream wine project. If it can go upstream, then that should be done first, and then use this merge request to track backporting the upstream commit.

[kakra]

If the hidraw support is also upstream, I'd send this upstream. Until then, I'd like to figure things out working here first maybe with support from the community.

I need to figure out if upstream has these hidraw patches. If they do, I'll rebase to latest wine for proper tracking here. Or maybe someone from Valve knows, @ivyl maybe?

[rbernon]

Sounds reasonable, if you say the device works better with hidraw. And yes, I believe there's some driver registry cache mechanism. I'm not completely sure how to override it.

Upstream doesn't yet have the same winebus.sys dual-backend mode as Proton, so this probably won't apply, although it would be nice to have it at some point.

[kakra]

Sounds reasonable, if you say the device works better with hidraw.

It only works with hidraw, otherwise mappings within wine are completely messed up and xinput devices seem to generate contradicting inputs with more than half of the axes and buttons dead.

[kakra]

And yes, I believe there's some driver registry cache mechanism. I'm not completely sure how to override it.

@rbernon Yes it seems like it is exactly that: a cache. A way to override or invalidate it would be mostly useful as it improves end-user experience a lot and reduces support burden when new devices are supported or added through PROTON_ENABLE_HIDRAW. Otherwise, people would need to be instructed to properly clear out the registry entries.

Also, this needs added entries for the Steam udev rules. Should I file a PR? If I remember correctly, there's a Valve repo for that.

[kakra]

@kisak-valve @rbernon This doesn't apply to wine upstream because it is missing is_hidraw_enabled() and the surrounding logic.

I've modified the decision logic to also being able to look at the amount of buttons and axes. This way, we can do a more generic approach to identifying modern and highly customizable HOTAS because they often come with a fixed and high amount of HID buttons (used for macro programming at the hardware level).

I didn't test it in action (because the Proton build scripts currently do not work for me) but the code seems to compile.

To be used with: ValveSoftware/steam-devices#51

[kakra]

For some reason, after a reboot, the joysticks become recognized as xinput devices again. It looks like SDL feeds them back into wine although they were deferred to a different backend and I set SDL to ignore those devices:

0084:trace:hid:maybe_add_devnode Creating udev_device for /sys/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.4/1-4.4:1.0/0003:231D:0200.0046/hidraw/hidraw6
0084:trace:hid:maybe_add_devnode Adding device for /sys/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.4/1-4.4:1.0/0003:231D:0200.0046/hidraw/hidraw6
0084:trace:hid:udev_add_device udev "/dev/hidraw6" syspath /sys/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.4/1-4.4:1.0/0003:231D:0200.0046/hidraw/hidraw6
0084:trace:hid:get_device_subsystem_info hid uevent "DRIVER=hid-generic"
0084:trace:hid:get_device_subsystem_info hid uevent "HID_ID=0003:0000231D:00000200"
0084:trace:hid:get_device_subsystem_info hid uevent "HID_NAME=VKB-Sim \xc2\xa9 Alex Oz 2021  VKBsim Gladiator EVO  R  "
0084:trace:hid:get_device_subsystem_info hid uevent "HID_PHYS=usb-0000:00:14.0-4.4/input0"
0084:trace:hid:get_device_subsystem_info hid uevent "HID_UNIQ="
0084:trace:hid:get_device_subsystem_info hid uevent "MODALIAS=hid:b0003g0001v0000231Dp0000020"
0084:trace:hid:get_device_subsystem_info usb uevent "DEVTYPE=usb_interface"
0084:trace:hid:get_device_subsystem_info usb uevent "DRIVER=usbhid"
0084:trace:hid:get_device_subsystem_info usb uevent "PRODUCT=231d/200/2122"
0084:trace:hid:get_device_subsystem_info usb uevent "TYPE=0/0/0"
0084:trace:hid:get_device_subsystem_info usb uevent "INTERFACE=3/0/0"
0084:trace:hid:get_device_subsystem_info usb uevent "MODALIAS=usb:v231Dp0200d2122dc00dsc00dp00ic03isc00ip00in0"
0084:trace:hid:udev_add_device hidraw "/dev/hidraw6": deferring {vid 231d, pid 0200, version 2122, input 0, uid 00000000, is_gamepad 0} to a different backend

But then:

008c:trace:xinput:add_device device 0000000000F8A310, bus_id L"WINEBUS", device_id L"WINEXINPUT\\VID_231D&PID_0200", instance_id L"273&0300b0871d2300000002000011010000.0&0&0".
008c:trace:plugplay:load_function_driver AddDevice routine 00000001D43F1590 returned 0.
008c:trace:xinput:fdo_pnp device 0000000000F8A310, irp 00000000009108F0, code 0, bus_device 0000000000F7D080.
008c:trace:hid:pdo_pnp_dispatch device 0000000000F7D080, irp 00000000009108F0, minor function 0.

although it clearly said is_gamepad: 0 before...

Full log: steam-359320.log

[rbernon]

Isn't this simply the driver cache in action? It's something in setupapi I believe, but I don't really know how we can invalidate it. Maybe it could check whether the DeviceIds / HardwareIds / CompatibleIds have changed since last time, and invalidate itself if it is the case (we report WINEBUS\WINE_COMP_XINPUT CompatibleId only if gamepad is set to 1).

[rbernon]

Would this properly invalidate the cache?

diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c
index ae676f80565..77c4a392368 100644
--- a/dlls/winebus.sys/main.c
+++ b/dlls/winebus.sys/main.c
@@ -189,7 +189,10 @@ static WCHAR *get_instance_id(DEVICE_OBJECT *device)
     WCHAR *dst;
 
     if ((dst = ExAllocatePool(PagedPool, len * sizeof(WCHAR))))
-        swprintf(dst, len, L"%i&%s&%x&%i", ext->desc.version, ext->desc.serialnumber, ext->desc.uid, ext->index);
+    {
+        swprintf(dst, len, L"%u&%s&%x&%u&%u", ext->desc.version, ext->desc.serialnumber,
+                 ext->desc.uid, ext->index, ext->desc.is_gamepad);
+    }
 
     return dst;
 }

[kakra]

@rbernon I see that also the internal Steam gamepad configuration sees these joysticks as Xbox gamepads. So what we observe may be resulting from Steam Input. Currently, I disabled the Steam overlay for that game (Elite Dangerous, because the overlay somehow sometimes triggered itself without pressing shift+tab). This probably also means, Steam Input is not working for the game, and I haven't seen the issue from my previous comment again:

For some reason, after a reboot, the joysticks become recognized as xinput devices again...

From that perspective, I'd say your above suggestion should work because it includes is_gamepad. But I cannot construct a situation currently for testing it.

[rbernon]

I've merged this internally, will be in a future Proton Experimental release.