The issue I was working on when I did the initial implementation was making the Sidewinder work for a flight simulator I use (I still have to implement [loading effect for a file API](https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ee417886...)) to complete this). As there was originally no support for `DIPROP_AUTOCENTER` (it was ignored), the default autocentering never got turned off, and so autocentering was overlaid on top of everything.
I based the patch on reading the USB PID spec and testing my device under Windows and Linux. Under Windows I snooped the USB packets (thanks wireshark) and under Linux I read through the actual driver code. One item that concerned me is I didn't want autocentering to waste an effect slot, as there aren't a lot of them on the Sidewinder, hence why hooked into the Linux FF autocentering API instead of emulating anything with a spring effect.
From your commit, I believe you are turning autocentering off on device reset? This would be different behaviour than I saw with my Sidewinder under Windows? Am I correct then in understanding that you are saying the reason you are doing this is that
1. my implementation has all devices turning on autocentering on reset, while 2. under Windows all devices, but the Sidewinder, turn off autocentering on reset?
In other words, the Windows dinput FF world is a mess whereby code that was written where the developers were testing with the Sidewinder (e.g., flying simulators) are written expecting auto centering to be enabled on reset, while codes that were written were the developers were using wheels (e.g., driving simulators) are written to not expect auto centering to be enabled on reset?