This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• 0001-clarify-direction-parameter (0001-clarify-direction-parameter.patch, text/plain, 2014-10-25 12:23:20 +0000, 1352 bytes)
• 0002-clarify-phase-parameter (0002-clarify-phase-parameter.patch, text/plain, 2014-10-25 12:24:00 +0000, 705 bytes)
• 0003-fix-linux-phase-handling (0003-fix-linux-phase-handling.patch, text/plain, 2014-10-25 12:25:26 +0000, 1216 bytes)

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

Comments on the original bug report:

On 2014-10-25 12:21:58 +0000, Elias Vanderstuyft wrote:

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(2pit + phase) instead of waveform(2pit - 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.

On 2014-10-25 12:23:20 +0000, Elias Vanderstuyft wrote:

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

On 2014-10-25 12:24:00 +0000, Elias Vanderstuyft wrote:

Created attachment 1917
0002-clarify-phase-parameter

"Horizontal" is not very precise, use "Positive phase" instead.
"Positive" because it's actually waveform(2pit + phase) instead of waveform(2pit - phase).

On 2014-10-25 12:25:26 +0000, Elias Vanderstuyft wrote:

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

On 2014-11-29 19:51:31 +0000, Sam Lantinga wrote:

Patches applied, thanks!