https://bugs.winehq.org/show_bug.cgi?id=51873
--- Comment #8 from Ivo Ivanov logos128@gmail.com --- I continued working on this and so far have fully functioning FFB device in HIDRAW mode in almost all tested games and apps. The FFB works very well like in Windows, and generally the setup of the wheel (Simucube 2 Sport) and the pedals (Fanatec Clubsport Pedals) in games doesn't need any additional tweaking, once the prefix is setup for hidraw, etc. Managed to capture some usb traffic from the WheelCheck app (from iRacing) to confirm that the usb data and the sequence of the reports is pretty similar between Windows 10 and Wine. Especially the direction field in the Set Effect Report, as well as other fields in the constant, periodic and condition reports.
Needed to implement few additional reports - Create New Effect Report, PID Block Load Report and PID Block Free Report, which are required by the devices managing the Parameter Blocks on the device side. Also implemented Device Gain Report and the DIPROP_FFGAIN property as well. Added support for few additional properties, which are needed by various games and apps to function properly. For example the WheelCheck application needed DIPROP_PHYSICALRANGE to correctly calculate the top center of the steering wheel against its permitted range. This fixed the constant force test pulling the wheel hard to the left. Now it works just like in Windows, directing the wheel to the upper center and resisting any movement to left or right. Fixed as well few other issues.
There are still few remaining issues, though. For example BeamNG doesn't have FFB due to the not implemented GetEffectStatus. They create the effect in an acquired state, and then strangely call GetEffectStatus, to find out if it's started. Lately they push constant reports through SetParameters (Download), without ever starting the effect, since the GetEffectStatus returns DIERR_UNSUPPORTED. Proton's joystick_sdl mitigate this issue with always returning DI_OK, even if the function doesn't support all devices. This way it may work depending on how the *status is initialized :) The WheelCheck application is also affected, as they use the function to update the state of the effects in real time.
In the PID specification there is a PID State Input Report, which needs Get Input Report request through the control channel, as it is not sent freely on the Simucube 2 for example. I'll probably try to implement the functionality in the winebus.sys, but anyway the effect status can be implemented on the dinput part as well.
Attached the patchset with the needed changes. Rebased on the latest master 6a072b98c100f38a61fad00b6c96c86b3445efac
P.S. Just saw in the winehq patch list that you have worked on the issue with the not allowed single-axis effects with Cartesian coordinates, etc. Still leaving my patches on the issue for reference :)