https://bugs.winehq.org/show_bug.cgi?id=51873
--- Comment #18 from Ivo Ivanov logos128@gmail.com --- (In reply to Rémi Bernon from comment #17)
Thanks, I had it rebased already and I started upstreaming the patches after tweaking them a bit.
For the patch to only send modified reports, I'm not sure it's right, at least according to the conformance tests, although it could be some device specific behavior.
According to the conformance tests, the generic PID driver always seems to send the reports, regardless of whether they are actually different from the previous one or not.
I just realized this myself. Finally captured some usb traffic from my gaming machine, since till now used VMs to capture some traffic from Windows.
They (MS) don't send all the reports, though. Just those that have been probably set through the dwFlags parameter of SetParameters, and seems the whole logic conforms to the SetParameters documentation.
For example BeamNG sends one Set Effect Report with infinite duration, one Effect Operation Report (to start the report) and then starts pushing thousands of Set Constant Force Reports ~260Hz.
On other side Project Cars 2 and Automobilista 2, which use the Madness physic engine, send one Effect Operation Report to start the effect, and then start pushing couples of Set Effect Report with infinite duration and Set Constant Force Report. The Set Effect Report is exactly the same through the whole session, and according to the MS documentation is not needed, since the dynamic effect parameters can be changed on the fly during the effect duration, as if the effect was started with the new values. Seems the PID specification follows this logic, or probably the device manufacturers follow it :)
Automobilista 2 sends FFB reports with ~400Hz rate, which is doubled to 800Hz with unneeded Set Effect Reports, since they probably call SetParameters with something like DIEP_DURATION, DIEP_GAIN, DIEP_STARTDELAY, etc., in addition to the DIEP_TYPESPECIFICPARAMS.
So, according to the usb traffic captures of the Simucube 2, the PID driver probably follows the logic of the SetParamers' dwFlags, and sends only the reports which are requested through the dwFlags.
Was it actually required for your device or just an optimization?
I have followed the logic of the Linux PID driver. For example Automobilista 2 on Proton/Wine sends (through joystick_sdl) only Set Constant Force reports with ~550Hz rate, which is 150Hz more than Windows. Even if on Windows the rate is ~800Hz, only half of it is useful for the device. They probably try to send more, but unfortunately reach the bus limits :)