https://bugs.winehq.org/show_bug.cgi?id=40658
--- Comment #33 from Paul geoff.pvgn1@gmail.com --- (In reply to Rémi Bernon from comment #31)
I'm definitely not opposed to make the axis mapping configurable somehow, to help with bogus devices and users, just that doing it in DInput like it was done before doesn't seem right anymore.
Wine now exposes any host joystick as an HID device internally, and DInput is only one of the many ways to access them. Applications may use HID APIs directly, and I know several middleware are doing it instead of DInput which is kind of considered as legacy.
So having a customizable mapping in winebus.sys instead, for when where we convert evdev axes to HID usages makes more sense, it's just not implemented yet.
Of course, that won't cover cases where Wine simply acts as a pass-through, like with hidraw devices, or where the mapping is already done elsewhere, like with SDL.
I admit that would take care of the current situation. Per-application mapping should be a non-issue with separate prefixes, as is recommended, and should be further encouraged by distro wikis.
I've run across apps that used raw input (Everspace I think it was?). The only way to correct it was through the device node, which loops us back to the beginning of the discourse.
Of course, hearing wine implement SDL in this way brings me back to all the terrible times, as an end user, I had trying to make sense of their wiki. This lists some up-to-date tools, though I'm not sure how relevant this will be to wine. https://github.com/gabomdq/SDL_GameControllerDB
Of course that should read "help the users", not help with bogus users.
Yeah, we shouldn't help them, stupid non-sentient wannabe humans.