[PATCH 0/1] Allow negative attack/fade ramps

[PATCH 0/1] Allow negative attack/fade ramps

[Kalle Jokiniemi]

Hi,

We're using ff-memless in Sailfish OS for vibrator / haptics support,
and I've noticed this annoying issue with the periodic force feedback effects
that declining attack ramps don't work with it properly.

I.e This kind of effect:

\
 \
  '-------------.
                 \
                  \

turns into something like this:

--+
  |
  +-------------.
                 \
                  \

It turned out to be quite simple fix to get declining attack ramps
and rising fades to behave linearly. Please check, comment, and apply
if seen fit.

Kalle Jokiniemi (1):
  input: ff-memless: Allow negative attack / fade ramps

 drivers/input/ff-memless.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH 1/1] input: ff-memless: Allow negative attack / fade ramps

[Kalle Jokiniemi]

Currently the ff-memless force feedback periodic effects can only
have rising attack periods and declining fade periods. E.g. setting
a attack ramp that starts high to lower to normal magnitude, will
just cause the effect to rumble at high static speed for duration
of the attack period and then abruptly lower back to normal
magnitude instead of linearly declining the effect during attack
phase.

To fix this, a check has been added to see if the envelope_level
of the attack or fade period is higher than default magnitude or
vise versa, and then adjusting the difference value calculation
accordingly.

Signed-off-by: Kalle Jokiniemi <kalle.jokiniemi@jolla.com>
---
 drivers/input/ff-memless.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
index 0723e0d..487df7e 100644
--- a/drivers/input/ff-memless.c
+++ b/drivers/input/ff-memless.c
@@ -190,7 +190,10 @@ static int apply_envelope(struct ml_effect_state *state, int value,
 	} else
 		return value;
 
-	difference = abs(value) - envelope_level;
+	if (abs(value) >= envelope_level)
+		difference = abs(value) - envelope_level;
+	else
+		difference = -(envelope_level - abs(value));
 
 	pr_debug("difference = %d\n", difference);
 	pr_debug("time_from_level = 0x%x\n", time_from_level);
-- 
1.9.1

Re: [PATCH 1/1] input: ff-memless: Allow negative attack / fade ramps

[Kalle Jokiniemi]

Hi,

Please disregard this patch, the math doesn't really change with this. I 
need to dig deeper what really was the issue, as I could see the 
negative ramp not working.

- Kalle

On 27.08.2015 14:03, Kalle Jokiniemi wrote:
> Currently the ff-memless force feedback periodic effects can only
> have rising attack periods and declining fade periods. E.g. setting
> a attack ramp that starts high to lower to normal magnitude, will
> just cause the effect to rumble at high static speed for duration
> of the attack period and then abruptly lower back to normal
> magnitude instead of linearly declining the effect during attack
> phase.
>
> To fix this, a check has been added to see if the envelope_level
> of the attack or fade period is higher than default magnitude or
> vise versa, and then adjusting the difference value calculation
> accordingly.
>
> Signed-off-by: Kalle Jokiniemi <kalle.jokiniemi@jolla.com>
> ---
>   drivers/input/ff-memless.c | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
> index 0723e0d..487df7e 100644
> --- a/drivers/input/ff-memless.c
> +++ b/drivers/input/ff-memless.c
> @@ -190,7 +190,10 @@ static int apply_envelope(struct ml_effect_state *state, int value,
>   	} else
>   		return value;
>
> -	difference = abs(value) - envelope_level;
> +	if (abs(value) >= envelope_level)
> +		difference = abs(value) - envelope_level;
> +	else
> +		difference = -(envelope_level - abs(value));
>
>   	pr_debug("difference = %d\n", difference);
>   	pr_debug("time_from_level = 0x%x\n", time_from_level);
>

Re: [PATCH 1/1] input: ff-memless: Allow negative attack / fade ramps

[Kalle Jokiniemi]

Hi,

On 28.08.2015 17:04, Kalle Jokiniemi wrote:
> Hi,
>
> Please disregard this patch, the math doesn't really change with this. I
> need to dig deeper what really was the issue, as I could see the
> negative ramp not working.

It seems the mis-interpretation of negative ramps not working was my 
personal user error of trying to do it with too short effects and 
FF_ENVELOPE_INTERVAL being 50ms.

Sorry for the noise.

- Kalle


>
> - Kalle
>
> On 27.08.2015 14:03, Kalle Jokiniemi wrote:
>> Currently the ff-memless force feedback periodic effects can only
>> have rising attack periods and declining fade periods. E.g. setting
>> a attack ramp that starts high to lower to normal magnitude, will
>> just cause the effect to rumble at high static speed for duration
>> of the attack period and then abruptly lower back to normal
>> magnitude instead of linearly declining the effect during attack
>> phase.
>>
>> To fix this, a check has been added to see if the envelope_level
>> of the attack or fade period is higher than default magnitude or
>> vise versa, and then adjusting the difference value calculation
>> accordingly.
>>
>> Signed-off-by: Kalle Jokiniemi <kalle.jokiniemi@jolla.com>
>> ---
>>   drivers/input/ff-memless.c | 5 ++++-
>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
>> index 0723e0d..487df7e 100644
>> --- a/drivers/input/ff-memless.c
>> +++ b/drivers/input/ff-memless.c
>> @@ -190,7 +190,10 @@ static int apply_envelope(struct ml_effect_state
>> *state, int value,
>>       } else
>>           return value;
>>
>> -    difference = abs(value) - envelope_level;
>> +    if (abs(value) >= envelope_level)
>> +        difference = abs(value) - envelope_level;
>> +    else
>> +        difference = -(envelope_level - abs(value));
>>
>>       pr_debug("difference = %d\n", difference);
>>       pr_debug("time_from_level = 0x%x\n", time_from_level);
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html