https://bugs.winehq.org/show_bug.cgi?id=51922
--- Comment #13 from Rémi Bernon rbernon@codeweavers.com --- Okay, maybe I just got confused with all the conversions.
I did some tests with BeamNG, checking what we were previously passing to the legacy dinput Linux evdev backend, and making sure winebus.sys is doing the same.
In my test the game used a 1 axis effect with a single -1 direction set to cartesian coordinate. As it's just 1 axis, the direction doesn't have any effect here, and the default direction is used, which is 0 in spherical coordinates or 90° in polar (force coming from the east or user's right).
This was previously converted to a Linux evdev direction of 0xc000, which if I understand correctly what SDL source describes, is a force "pulling into the 270° direction", so pulling into west or user's left.
With the new driver this gets written to Wine PID reports as a single 9000 (0x2328) direction value, which should be visible on the +hid debug channel. And I changed the evdev backend to map it to 0xc000, like we were doing before, and this seemed to match some comment in SDL code too [1].
Then I haven't checked how this gets translated again by the Linux evdev driver down to Linux kernel HID reports, maybe it just passes it unmodified and there's some different expectations between devices?
[1] That part of https://github.com/libsdl-org/SDL/blob/main/src/haptic/linux/SDL_syshaptic.c... is a bit confusing though, as the SDL_HAPTIC_SPHERICAL case seems to do a simple direct mapping, unless SDL_HAPTIC_SPHERICAL and SDL_HAPTIC_POLAR are inverted but I don't see any clue that they are. Maybe it's all wrong and maybe we should not change the coordinates at all for evdev.
Would you mind checking if reverting the lnxev_device_physical_effect_update change in b431dceeca9aa0d4229c3597b833bcaf04de7110 makes it correct now?