On Mon Nov 21 11:07:33 2022 +0000, Rémi Bernon wrote:
Thanks for spotting this! Do you think you could add a few tests to check the HidP_SetUsageValue change? Like in `test_hidp` (the descriptor being in `test_hid_driver`) in `dlls/dinput/tests/hid.c`?
I've added some tests, although I've just realized `HidP_SetScaledUsageValue` and `HidP_Get[Scaled]UsageValue` likely have the same bug.
I also wanted to mention a [couple hacks](https://gitlab.winehq.org/0e4ef622/wine/-/commit/5c28d1f7f5436c5428b51962570...) I had to add to get my controller to fully work.
1. The USB HID interface providing controls defines 3 top-level collections: mouse, keyboard and joystick. Currently, the driver looks at the first one and calls the entire thing a mouse, and joystick inputs are not delivered. I think the proper solution would be to "generate a unique physical device object (PDO) for each Top Level Collection" ([ref](https://learn.microsoft.com/en-us/windows-hardware/drivers/hid/top-level-col...)). 2. The thread which receives HID input reports and makes `send_hardware_message` requests to wineserver does not have an associated desktop. This causes wineserver to return STATUS_INVALID_HANDLE and thus no rawinput messages get queued.
How hard would it be to fix these in a more "proper" way?