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

Summary: Haptic coding bugs and fixes for Linux FF: periodic.phase handled as time instead of angle; + direction clarification
Product: SDL Reporter: Elias Vanderstuyft <Elias.vds>
Component: hapticAssignee: Edgar Simo <bobbens>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: Elias.vds
Version: HG 2.1   
Hardware: All   
OS: Linux   
Attachments: 0001-clarify-direction-parameter
0002-clarify-phase-parameter
0003-fix-linux-phase-handling

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!