This needlessly complicates a non issue. I don't know if purposefully or not but you're completely missing the point of https://gitlab.winehq.org/wine/wine/-/merge_requests/8605. If you woul actually understand what I was saying, my device doesn't even support autocenter natively and the PR was made on behalf on a wider community. Yes, I was testing this as well with my work to bring effect based autocenter support to `hid-pidff` driver but I can't really use this as a real argument if it's not upstream and fully usable.
1. This duplicates what's already in wine when it comes to registry properties 2. It's not just "my" issue, this autocenter behavior on SDL/udev is unwanted by a big part of community as it was just fine. Again, modifying autocenter outside of an ffb application is a valid use case on Linux. Of course, Wine is not Linux, but as Linus said "If it's a bug that people rely on it's not a bug, it's a feature" 3. Applying registry overrides to 30 separate proton prefixes is not easy nor a robust solution 4. Autocenter is a minor part of force feedback. Moreover, games are encouraged to use spring + friction/damper to properly manage active autocentering. It's not a core effect and doesn't affect "real" gameplay. IMO forcing end users to use overrides to "fix" misbehaving games is not great from usability standpoint where the previous behavior was working just fine and doesn't require any actions on their part. 5. Do we really need another "quirks" list/database that will grow endlessly, especially tracked outside of wine? 6. As I said before, this could be revisited when Linux force-feedback api is improved and more fleshed-out.
I said my piece and explained myself and the simracing community's point at length and as best as I can. Whatever may come, we'll deal with and I won't defy what Wine developer this is the proper solution. Please, kindly stop tagging me now.