https://bugs.winehq.org/show_bug.cgi?id=51873
--- Comment #13 from Rémi Bernon rbernon@codeweavers.com --- I see.
It could be possible to do it the same way as feature reports but the problem I'm seeing there is that IOCTL_HID_GET_INPUT_REPORT needs to be explicitly requested and I don't see how it would specify the event number it's interested in.
Is HIDIOCGINPUT returning an error if there's no more input report for the matching id, or is it blocking until there's one?
If it's the case, we'll maybe have to implement IOCTL_HID_GET_INPUT_REPORT in the same kind of way then, instead of succeeding every time and returning the last report seen. This would need to be the case for all the backend though, and maybe not completely straightforward.
The client (dinput) will also need to make a dedicated asynchronous ioctl to read effect statuses, instead of reading them in the same way as the device state reports.
Another possible approach would be to do like the SDL backend, where we would request HIDIOCGINPUT regularly and push the report in the same way as device state reports. That may be simpler from the client perspective as we wouldn't have to worry whether a device needs IOCTL_HID_GET_INPUT_REPORT requests or just ReadFile calls.