On Thu Jul 31 16:42:49 2025 +0000, Rémi Bernon wrote:
We implement the HID PID protocol the way Microsoft does it in dinput.dll, and it has some autocenter semantics we cannot really change without breaking hidraw support (ie: autocenter should be enabled after PID_USAGE_DC_DEVICE_RESET is received on the device side, disabled after PID_USAGE_DC_STOP_ALL_EFFECTS is received. DInput will send PID_USAGE_DC_STOP_ALL_EFFECTS right after PID_USAGE_DC_DEVICE_RESET if autocenter has been disabled on the device by the application). We can possibly consider adding some Wine-specific bits in the report descriptors, implemented on both dinput and winebus sides to better support SDL/evdev cases, but neither SDL nor evdev seem to have detailed enough API to control these things, and it doesn't solve any vendor-specific behavior problem we may have. Many vendors don't use the generic HID PID DInput driver on Windows but ship their own DInput and NT device driver. Applications may embed specific knowledge of these devices, and of their Windows drivers behavior. For these, either we would either need to rewrite each vendor driver, which is probably not something we want to do, or we need to work to make the Windows driver work in Wine.
Okay, yeah. I think I finally understand the issue at hand here. The autocenter behavior can/is different for other drivers, but since everything in Wine passes through PID, that's they way everything will behave on the other side.
Since no FFB racing wheel that's build upon PID supports this non-standard auto-centering, some games might not actually disable autocenter properly because it didn't come up in their testing.
In my testing, I found that `PID_USAGE_DC_STOP_ALL_EFFECTS` does not actually always come after reset, at least in ETS2/ATS but maybe this game actually check first if the device supports autocenter, instead of just blindly disabling it?