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

On Jun 13, 2016, at 12:11 AM, David Lawrie <david.dljunk@gmail.com> wrote:
>
> Adds support for input features defined by HID Simulation page: Rudder
> (Rz), Throttle (Z), Steering (X), Accelerator (Y), Brake (Rz).

> +static int axis_for_usage_Sim(int usage)
> +{
> +�� switch (usage)
> +�� {
> +�� case kHIDUsage_Sim_Rudder: return AXIS_RZ;
> +�� case kHIDUsage_Sim_Throttle: return AXIS_Z;
> +�� case kHIDUsage_Sim_Steering: return AXIS_X;
> +�� case kHIDUsage_Sim_Accelerator: return AXIS_Y;
> +�� case kHIDUsage_Sim_Brake: return AXIS_RZ;
> +�� }

Is it intentional that Rudder and Brake both map to the same axis?�� Later, when enumerating elements, which comes first and thus "wins" the collision (if they ever appear on the same device) is arbitrary based on enumeration order.�� That OK?

Yeah I think that's fine as it's unlikely that the same joystick/gamepad/controller will have both a listed Rudder and a listed Brake axis as one is generally found on a device to control sim-planes and the other to control sim-cars. So this is a case where a controller might call its RZ axis GD_RZ, Brake, or Rudder depending on the device. Instead of GD_X or GD_Y a car controller might call it steering and accelerator. Instead of a slider, a joystick might list a throttle. The Linux version had some of these too and I thought it better than not just to check in case. I realized I did put the wrong link into the comment however. It should've been this one:��https://msdn.microsoft.com/en-us/library/windows/hardware/ff538338(v=vs.85).aspx

��

> @@ -404,66 +418,100 @@ static void collect_joystick_elements(joystick_t* joystick, IOHIDElementRef coll
>�� break;
>�� }
>�� case kIOHIDElementTypeInput_Axis:
> -�� {
> -�� TRACE("kIOHIDElementTypeInput_Axis; ignoring\n");
> -�� break;
> -�� }
>�� case kIOHIDElementTypeInput_Misc:

It seems that treating kIOHIDElementTypeInput_Axis the same as kIOHIDElementTypeInput_Misc is a separate issue from adding support for the Sim page inputs.�� Or is there an interrelationship that I'm not aware of?�� Is it the case that both Axis and Misc elements can be present with either GD or Sim usage pages?

Some of the debug logging statements have been changed to say "kIOHIDElementTypeInput_Axis/Misc" while others have been left as "kIOHIDElementTypeInput_Misc".�� Is that indicative of something or just an oversight?

Mostly it's because I wasn't sure how the Sim page axes would be listed - under Axis or under Misc. For instance, I was very surprised to see the Generic_Desktop axes listed under Misc instead of Axis. Do you know why that is? If the GD_X_Axis is under Misc, not Axis, what's under Axis? The Mac HID documentation was even more confusing than the Microsoft documentation! (at least for me). The changes in the debug statements is because the general/default case could now be a Axis or Misc type, but the Generic_Desktop page axes are known Misc types. So I decided one but not the other. Not changing the Sim page axes debug statement on line 496 to Axis/Misc to reflect my lack of knowledge as to how they would be listed was indeed an oversight. However, we can go back to ignoring the reported Axes elements, but I noticed the dinput code didn't ignore them and neither did several other examples of OS X joystick programs I found on the web. So I thought, why not just have the axis-type fall through, since I'm not actually sure what falls under axis versus misc, and try to catch everything? That was my thinking. ��

��

> @@ -614,7 +662,7 @@ LRESULT driver_joyGetDevCaps(DWORD_PTR device_id, JOYCAPSW* caps, DWORD size)
>�� {
>�� int i;
>
> -�� /* complete 95 structure */
> +�� /* complete Win95 structure */

This is an unrelated change.

I'd forgotten I'd even made that change. :) That was for myself because I wasn't sure what 95 meant until I looked at the Linux code and saw Win95 and figured out the rest. So I changed the comment to remind myself what that piece of code did. It's not particularly important to keep.��

��

-Ken