Correlating traditional Windows joystick axes with HID

Question

I'm a bit confused on the description of joystick axes and I'm hoping that someone has a link or document which could help clear my confusion.

I'm not a Windows guy, so trying to port some traditional Windows gameport code has me a bit confused.

We all know about the common first three axes:
X
Y
Z

My understanding was that in the gameport-style interface the three other axes are:
R
U
V

However, looking in my IOHIDUsageTables (OS X), I see:

kHIDUsage_GD_X  = 0x30, /* Dynamic Value */
kHIDUsage_GD_Y  = 0x31, /* Dynamic Value */
kHIDUsage_GD_Z  = 0x32, /* Dynamic Value */
kHIDUsage_GD_Rx = 0x33, /* Dynamic Value */
kHIDUsage_GD_Ry = 0x34, /* Dynamic Value */
kHIDUsage_GD_Rz = 0x35, /* Dynamic Value */

kHIDUsage_GD_Vx = 0x40, /* Dynamic Value */
kHIDUsage_GD_Vy = 0x41, /* Dynamic Value */
kHIDUsage_GD_Vz = 0x42, /* Dynamic Value */
kHIDUsage_GD_Vbrx   = 0x43, /* Dynamic Value */
kHIDUsage_GD_Vbry   = 0x44, /* Dynamic Value */
kHIDUsage_GD_Vbrz   = 0x45, /* Dynamic Value */
kHIDUsage_GD_Vno    = 0x46, /* Dynamic Value */

This has me a bit confused due to the three R axis (though that does not appear to be uncommon) and the lack of a U axis.

Two questions:

1) Can anyone confirm to what axis the traditional U axis would be? I saw one document describe it as "the axis for rudder pedals" leading me to believe it would be Ry.
2) Can anyone describe in more detail the typical usages of the V and Vbr axes? I understand the descriptions are "vector" and "relative vector,' respectively, but I'm having difficult visualizing what that means in terms of a physical device.

All enlightenment and documentation pointers welcome.

Answer 1

There are 2 different conventions here with confusingly similar naming:

• Position, (R)otation and/or (V)elocity for each of the x, y, z axes
• (R), (U), (V) axes

It might be the case that the R, U, V axes map directly onto 3 of the HID slots, whichever ones they may be. Or it might be the case that the drivers do something else, depending on which exact piece of hardware it is.

Personally I wouldn't spend too much time worrying about what each axis 'means' or whether they can be mapped directly. Each joystick has different physical controllers which will be mapped by the drivers in an arbitrary way. So beyond X and Y it's difficult to anticipate what axes will be used for each function. And even if you can guess the original intention, it's likely that a user may wish to override the defaults. So it's probably best to implement your axis mapping via a settings file that can be configured on a per-device and per-user basis.