https://bugs.winehq.org/show_bug.cgi?id=52062
--- Comment #2 from Ivo Ivanov logos128@gmail.com --- (In reply to Rémi Bernon from comment #1)
I wrote (and sent upstream) a few tests for these functions and as far as I can see, Microsoft PID driver isn't trying to read the effect state reports using IOCTL_HID_GET_INPUT_REPORT at all, but expects the reports to come alongside the device state input reports.
In any case, not having the reports implemented doesn't seem to be much of an issue, and DInput returns some default flags depending on the operations and the effects is knows have been created and started.
I thought the same. There is no sign of any Get_Input_Report requests in the captured usb traffic from Windows, either.
IMO it would need the start time (GetTickCount64(), etc.) and loop count from Start(), and duration from SetParameters(). Also if start delay is confirmed by a conformance test to be separate from the duration, it should be added to the equation as well. Probably would need a flag for the paused state too. Then there is the Solo mode in Start(), and the various FFB commands in SendForceFeedbackCommand(), which would need enumeration of the created effects and resetting (zeroing, etc.) their start times and probably the other state parameters.
Slightly more complicated look the Pause and Continue commands from SendForceFeedbackCommand(), which by documentation should pause the effect timers by their current step, and then continue playing for the remaining time. They would need enumeration of the created effects on Pause and clearing the start time, start delay, and reducing the duration to the remaining time, while flagging them as paused. Then Continue would set the start time of the paused effects, etc. All of this while also considering the Infinity duration and loop count.
This could be implemented as backup for the other method.