Created attachment 1815 [details]
Derivation of DInput 'polar' direction -> Linux direction conversion table

The initial problem description is written here:
    http://comments.gmane.org/gmane.comp.lib.sdl/65475
And the solution is provided here:
    http://permalink.gmane.org/gmane.comp.lib.sdl/67651
However I was advised to post this on bugzilla.

Here is the summarized version of the initial problem description:

1) One key point, is that Linux directions are defined as the direction of applied force, whereas DInput (and thus also SDL) directions are defined as the direction to counteract the resulting force (=> reversed).
Taking that into account, and some additional differences, we can summarize it and write a conversion table, this is done in the attached "DInputToLinuxDirectionConversion.txt" file.

2) SDL's haptic API follows the Linux FF API in the case of conditional effect parameters,
however the documentation (of both SDL and Linux) is not very clear about the allowed ranges.
I contacted Anssi Hannula to get certainty about these parameters, and he summarized:
- offset:    [-10000, 10000] (dinput)    ->    [-0x7FFF, 0x7FFF] (linux)
- deadband:  [     0, 10000] (dinput)    ->    [      0, 0xFFFF] (linux)
- p/n-coeff: [-10000, 10000] (dinput)    ->    [-0x7FFF, 0x7FFF] (linux)
- p/n-sat:   [     0, 10000] (dinput)    ->    [      0, 0xFFFF] (linux)

I will post the (6) patches as attachments in the next posts,
they also fix some additional things not specifically mentioned in the problem description,
but you'll find them in the patch summaries.
The patches are built on top of each-other.
Here is a summary and more detailed description of all patches:

---

vanilla-rev1.diff: Don't interpret a direction of polar 35999 (or linux-direction 0xFFFF) as "unsupported type".

rev1-rev2.diff: Fix the misconception that DInput's POLAR direction doesn't match Linux's direction.
    Note: this also solves a rounding bug that e.g. caused zero direction to give non-zero output of the X-force value.

rev2-rev3.diff: Explicitly avoid floating point arithmetic if it's not needed.
    This appears to be the common case in games, especially since the existence of multi-axes force-feedback devices is extremely small.

rev3-rev4.diff: Fix the misconception that Linux' saturation and deadband parameters - on which the corresponding SDL parameters were based - use only half of the possible range
    Note: untested on Darwin and Windows

rev4-rev5.diff: Fix a number of clamping bugs for Windows haptics, by using the Darwin haptics code
    Note: untested on Windows

rev5-rev6.diff: Add some missing haptic types to test, and fix wrong array-sizes

---