[v4 1/4] winejoystick.drv/joystick_osx.c: fixes Ry/Rx -> U/V axes mapping

DavidL david.dljunk at gmail.com
Tue Jun 14 00:57:02 CDT 2016


On Mon, Jun 13, 2016 at 2:44 PM, Ken Thomases <ken at codeweavers.com> wrote:

> On Jun 13, 2016, at 12:11 AM, David Lawrie <david.dljunk at 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).aspx
> >
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff543445(v=vs.85).aspx
> >
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160613/bcf39294/attachment.html>


More information about the wine-devel mailing list