We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2766 - Haptic coding bugs and fixes for Linux FF: periodic.phase handled as time instead of angle; + direction clarification
Summary: Haptic coding bugs and fixes for Linux FF: periodic.phase handled as time ins...
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: haptic (show other bugs)
Version: HG 2.1
Hardware: All Linux
: P2 normal
Assignee: Edgar Simo
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-25 12:21 UTC by Elias Vanderstuyft
Modified: 2014-11-29 19:51 UTC (History)
1 user (show)

See Also:


Attachments
0001-clarify-direction-parameter (1.32 KB, patch)
2014-10-25 12:23 UTC, Elias Vanderstuyft
Details | Diff
0002-clarify-phase-parameter (705 bytes, patch)
2014-10-25 12:24 UTC, Elias Vanderstuyft
Details | Diff
0003-fix-linux-phase-handling (1.19 KB, patch)
2014-10-25 12:25 UTC, Elias Vanderstuyft
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Elias Vanderstuyft 2014-10-25 12:21:58 UTC
orig        2.0.4-9165
p1          2.0.4-9165 + 0001-clarify-direction-parameter
p2          2.0.4-9165 + 0001-clarify-direction-parameter + 0002-clarify-phase-parameter
p3          2.0.4-9165 + 0001-clarify-direction-parameter + 0002-clarify-phase-parameter + 0003-fix-linux-phase-handling

0001-clarify-direction-parameter:
It's not obvious from the general "haptic direction" description what the SDL direction actually means in terms of force magnitude sign,
currently its meaning is only reflected by the example.

0002-clarify-phase-parameter:
"Horizontal" is not very precise, use "Positive phase" instead.
"Positive" because it's actually waveform(2*pi*t + phase) instead of waveform(2*pi*t - phase).

0003-fix-linux-phase-handling:
Remove the dependency of the calculation of Linux "phase" on "period",
currently the "phase" parameter is interpreted as a time shift, instead of a phase shift.
The Linux input documentation is not clear about the exact units of the "phase" parameter (see http://lxr.free-electrons.com/source/include/uapi/linux/input.h#L1075 ),
but we're about to standardize the 'phase shift' interpretation into the Linux input documentation,
since this will ease the job of a driver to recalculate the effect's state when the user dynamically updates the "period" parameter.
Comment 1 Elias Vanderstuyft 2014-10-25 12:23:20 UTC
Created attachment 1916 [details]
0001-clarify-direction-parameter

It's not obvious from the general "haptic direction" description what the SDL direction actually means in terms of force magnitude sign,
currently its meaning is only reflected by the example.
Comment 2 Elias Vanderstuyft 2014-10-25 12:24:00 UTC
Created attachment 1917 [details]
0002-clarify-phase-parameter

"Horizontal" is not very precise, use "Positive phase" instead.
"Positive" because it's actually waveform(2*pi*t + phase) instead of waveform(2*pi*t - phase).
Comment 3 Elias Vanderstuyft 2014-10-25 12:25:26 UTC
Created attachment 1918 [details]
0003-fix-linux-phase-handling

Remove the dependency of the calculation of Linux "phase" on "period",
currently the "phase" parameter is interpreted as a time shift, instead of a phase shift.
The Linux input documentation is not clear about the exact units of the "phase" parameter (see http://lxr.free-electrons.com/source/include/uapi/linux/input.h?v=3.17#L1075 ),
but we're about to standardize the 'phase shift' interpretation into the Linux input documentation,
since this will ease the job of a driver to recalculate the effect's state when the user dynamically updates the "period" parameter.
Comment 4 Sam Lantinga 2014-11-29 19:51:31 UTC
Patches applied, thanks!