https://bugs.winehq.org/show_bug.cgi?id=51822
--- Comment #5 from Ivo Ivanov logos128@gmail.com --- (In reply to Rémi Bernon from comment #4)
Thanks, this looks correct indeed I'll try to add some tests as well and upstream a fix.
Glad I can help! Pretty excited about the HID PID joystick implementation in dinput :) Will test it thoroughly when it's ready.
I'd like to mention another similar issue with this device descriptor, which I spotted while observing the log. This is part of Output report 1:
/* Usage (57h), */ /* Collection (Logical), */ /* Usage (000A0001h), */ /* Usage (000A0002h), */ /* Unit (Degrees), */ /* Unit Exponent (-2), */ /* Logical Minimum (0), */ /* Logical Maximum (180), */ /* Physical Minimum (0), */ /* Physical Maximum (36000), */ /* Unit, */ /* Report Size (8), */ /* Report Count (1), */ /* Output (Variable), */ /* Unit Exponent (0), */ /* Unit, */ /* End Collection, */
There are two ordered items Usages, but the Report Count is only 1. hidparse.sys parses this as two usages, with the second one being with RCnt 0. It's visible in the provided log, slightly above the previous issue. I believe this is correct in this situation (RCnt 0). Don't know how this would affect other parts of the logic though. Anyway, there is this line of code in parse_new_value_caps() (hidparse.sys/main.c):
if (!(is_array = HID_VALUE_CAPS_IS_ARRAY( &state->items ))) state->items.report_count -= usages_size - 1;
if usages_size is >= 3 and state->items.report_count is 1, then report_count would be a negative value if it was a signed integer, otherwise it would wrap around leading to undesired behavior. In my opinion this needs to be looked at too.
The descriptor doesn't look correct though. I'll contact Granite Devices for this issue, and hopefully they'll fix it themselves.
P.S. I have few more bugs (with patches) to report, mostly in hidclass.sys and one in winebus.sys, which affect mostly such HID devices with multiple reports/ReportIDs. Hopefully won't disturb you, or the other devs too much.