[Bug 51873] Joy.cpl crashes on the FFB tab when the FFB device is selected in the drop down list

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=51873

--- Comment #18 from Ivo Ivanov <logos128 at 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 :)

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.