Re: [v4 1/4] winejoystick.drv/joystick_osx.c: fixes Ry/Rx -> U/V axes mapping
On Jun 13, 2016, at 12:11 AM, David Lawrie <david.dljunk(a)gmail.com> wrote:
Ry now maps to U, Rx now maps to V. Windows defines Winmm U as Dinput Ry and V as Dinput Rx. Original joystick_osx.c mapping was other way around. This is also a bug in the Linux Winmm joystick version (not fixed with this patch).
Sources: https://msdn.microsoft.com/en-us/library/windows/hardware/ff538340(v=vs.85).... https://msdn.microsoft.com/en-us/library/windows/hardware/ff543445(v=vs.85)....
Tested on OS X 10.10.5.
Tested on Red Baron 3D, X-wing vs Tie Fighter, X-wing Alliance, Independence War deluxe w/ Logitech Extreme 3D pro and ControllerMate virtual joystick with 5/6 axes.
I originally wrote this code, but I think I was largely basing it on the Linux code without having a strong handle on the behavior of the R* axes. Your testing is probably the most thorough that's been done for the Mac code, although I would expect the Linux code to have been tested pretty well. Maybe the Linux code is correct and it's only the comments about what the joystick device is providing that are wrong. So, the code changes appear to properly implement the logic you've described above, but I don't know if that's correct. The cited MSDN pages are not terribly clear. That said, I would prefer if you kept the order of the axes enum the same (consistently x, y, z order) and changed the order of the axis_map table in driver_joyGetPosEx(), instead. -Ken
On Mon, Jun 13, 2016 at 2:44 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
On Jun 13, 2016, at 12:11 AM, David Lawrie <david.dljunk(a)gmail.com> wrote:
Ry now maps to U, Rx now maps to V. Windows defines Winmm U as Dinput Ry and V as Dinput Rx. Original joystick_osx.c mapping was other way around. This is also a bug in the Linux Winmm joystick version (not fixed with this patch).
Sources:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff538340(v=vs.85)....
https://msdn.microsoft.com/en-us/library/windows/hardware/ff543445(v=vs.85)....
Tested on OS X 10.10.5.
Tested on Red Baron 3D, X-wing vs Tie Fighter, X-wing Alliance, Independence War deluxe w/ Logitech Extreme 3D pro and ControllerMate virtual joystick with 5/6 axes.
I originally wrote this code, but I think I was largely basing it on the Linux code without having a strong handle on the behavior of the R* axes. Your testing is probably the most thorough that's been done for the Mac code, although I would expect the Linux code to have been tested pretty well. Maybe the Linux code is correct and it's only the comments about what the joystick device is providing that are wrong.
So, the code changes appear to properly implement the logic you've described above, but I don't know if that's correct. The cited MSDN pages are not terribly clear.
It's certainly possible that "case 3" in the Linux code is actually Ry, I don't actually know. However, I wanted to make a note of it, just in case, as at least the labels are reversed as to how the documentation says they should be (I agree they are not the most clear documents and I don't know why Ry,Rx <-> U,V rather than other way around, but consistently in the document tables, Winmm U maps to Dinput Ry and V maps to Rx and visa versa). This is not a scenario that would come up very often, if at all. For controllers: only 6-axes mice, multi-joystick setups, and virtual joysticks/gamepads created from a combination of physically created joysticks, none of which are common. For apps: I have no idea how many Winmm applications/games actually pay attention to input from Ry,Rx/U,V axes. Even if one does and if the person has the multiple axes, they may not even realize that two of those axes *should've* been swapped by default depending on how they are used. So it's possible for it to have been wrong and simply no one noticed or thought much of it. I only changed the mapping in the mac version, not because I encountered a problem, but because when reading about Winmm, Dinput, and HID I realized that both the Linux and Mac mappings were inconsistent with the documentation. I would've made the exact same original mapping a priori and it isn't explained in the documentation why Ry should map to U and not Rx to U.
That said, I would prefer if you kept the order of the axes enum the same (consistently x, y, z order) and changed the order of the axis_map table in driver_joyGetPosEx(), instead.
Sure I think I can change that. To make certain (line #s are for fully patched file): so instead of swapping lines 101-102 as I did, I would swap lines 734 & 735? That seems like the only change I would have to make to keep the original enum order and change the axes mapping ... does that seem right? (lines 687 & 688 would stay as I have them)
-Ken
On Jun 14, 2016, at 12:57 AM, DavidL <david.dljunk(a)gmail.com> wrote:
On Mon, Jun 13, 2016 at 2:44 PM, Ken Thomases <ken(a)codeweavers.com <mailto:ken(a)codeweavers.com>> wrote: That said, I would prefer if you kept the order of the axes enum the same (consistently x, y, z order) and changed the order of the axis_map table in driver_joyGetPosEx(), instead.
Sure I think I can change that. To make certain (line #s are for fully patched file): so instead of swapping lines 101-102 as I did, I would swap lines 734 & 735? That seems like the only change I would have to make to keep the original enum order and change the axes mapping ... does that seem right? (lines 687 & 688 would stay as I have them)
Yes, that's correct. Thanks, Ken
For the axes mapping, I think I figured out what the pattern is, why Ry maps to U and Rx to V. For the primary axes, the order is X, Y, Z. For the secondary/rotational axes, the expected fill order of the axes is Rz (joystick twist handle), Ry, Rx; they inverted the list and in Winmm these latter axes correspond to R, U, V. The newest patch (coming soon) will have the original enum order {X,Y,Z,Rx,Ry,Rz} and I've written next to the Rx,Ry,Rz comment labels with the corresponding Winmm mapping axes V, U, R. The axes mapping in joyPosEx has been changed to reflect the enum order. Cheers, David On Mon, Jun 13, 2016 at 11:28 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
On Jun 14, 2016, at 12:57 AM, DavidL <david.dljunk(a)gmail.com> wrote:
On Mon, Jun 13, 2016 at 2:44 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
That said, I would prefer if you kept the order of the axes enum the same (consistently x, y, z order) and changed the order of the axis_map table in driver_joyGetPosEx(), instead.
Sure I think I can change that. To make certain (line #s are for fully patched file): so instead of swapping lines 101-102 as I did, I would swap lines 734 & 735? That seems like the only change I would have to make to keep the original enum order and change the axes mapping ... does that seem right? (lines 687 & 688 would stay as I have them)
Yes, that's correct.
Thanks, Ken
participants (2)
-
DavidL -
Ken Thomases