Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Haptic coding bugs and fixes for Linux FF: inverted direction and faulty ranged conditional effect parameters #1606

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.1
Reported for operating system, platform: Linux, All

Comments on the original bug report:

On 2014-08-15 14:55:39 +0000, Elias Vanderstuyft wrote:

Created attachment 1815
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


On 2014-08-15 14:57:30 +0000, Elias Vanderstuyft wrote:

Created attachment 1816
Don't interpret a direction of polar 35999 (or linux-direction 0xFFFF) as "unsupported type".

On 2014-08-15 14:58:11 +0000, Elias Vanderstuyft wrote:

Created attachment 1817
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.

On 2014-08-15 14:59:28 +0000, Elias Vanderstuyft wrote:

Created attachment 1818
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.

On 2014-08-15 15:00:05 +0000, Elias Vanderstuyft wrote:

Created attachment 1819
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

On 2014-08-15 15:00:26 +0000, Elias Vanderstuyft wrote:

Created attachment 1821
Fix a number of clamping bugs for Windows haptics, by using the Darwin haptics code

Note: untested on Windows

On 2014-08-15 15:00:49 +0000, Elias Vanderstuyft wrote:

Created attachment 1822
Add some missing haptic types to test, and fix wrong array-sizes

On 2014-08-16 21:01:01 +0000, Ryan C. Gordon wrote:

These are all in revision control now, thanks!

https://hg.libsdl.org/SDL/rev/2412ba127e23
https://hg.libsdl.org/SDL/rev/a57a1d70ae07
https://hg.libsdl.org/SDL/rev/16b5dda99337
https://hg.libsdl.org/SDL/rev/8973a237f360
https://hg.libsdl.org/SDL/rev/8e04e17c7af3
https://hg.libsdl.org/SDL/rev/0c1a46c018aa

I really appreciate that you stuck with this work so long and kept reminding us to get these fixes in. I'm glad you kept at it.

--ryan.

On 2014-08-16 21:38:15 +0000, Elias Vanderstuyft wrote:

(In reply to Ryan C. Gordon from comment # 7)

These are all in revision control now, thanks!

https://hg.libsdl.org/SDL/rev/2412ba127e23
https://hg.libsdl.org/SDL/rev/a57a1d70ae07
https://hg.libsdl.org/SDL/rev/16b5dda99337
https://hg.libsdl.org/SDL/rev/8973a237f360
https://hg.libsdl.org/SDL/rev/8e04e17c7af3
https://hg.libsdl.org/SDL/rev/0c1a46c018aa

I really appreciate that you stuck with this work so long and kept
reminding us to get these fixes in. I'm glad you kept at it.

No problem, it was a pleasure to me! ;)
This project deserves good haptic support.

I still have to commit my equivalent patches for Wine (there are 30+ of them!), I'm afraid getting those in will be much harder, wish me luck (and time) ;-)

On 2014-08-17 01:54:04 +0000, Sam Lantinga wrote:

Good luck! :)

On 2014-08-17 08:00:16 +0000, Elias Vanderstuyft wrote:

(In reply to Sam Lantinga from comment # 9)

Good luck! :)

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant