- 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...)).
Is this exposed as a multiple top-level collection HID descriptor, ie: A single device with a HID descriptor with multiple root collections, like there's one in `dinput/tests/hid.c` / `test_hid_multiple_tlc`?
If that's the case we currently don't support that very well and indeed, we either discard the device entirely or just take the first collection, as you can see from the test. It's on my plate to do at some point but you're welcome if you're interested to work on implementing it.
Otherwise I think we should take Unix level devices separately and I'm not sure to see how this happens. You are using the udev / hidraw backend I presume? Also, HID mouse / keyboard are currently completely unsupported, they may be exposed as devices but I don't think they would work well with any application.
- 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.
I think that we're supposed to have a desktop there... or otherwise no controller would work at all. Maybe there's a regression? It should normally be created automatically as hidclass.sys links with user32 and uses __wine_send_input to send the HID messages.