* [PATCH] input: ff-memless: don't schedule already playing effect to play again
@ 2014-03-02 11:35 Felix Rueegg
2014-03-02 13:17 ` Elias Vanderstuyft
2014-03-04 17:07 ` Dmitry Torokhov
0 siblings, 2 replies; 6+ messages in thread
From: Felix Rueegg @ 2014-03-02 11:35 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Felix Rueegg
When an effect with zero replay length, zero replay delay
and zero envelope attack length is uploaded, it is played and then scheduled to play
again one timer tick later. This triggers a warning (URB submitted while
active) in combination with the xpad driver.
Skipping the rescheduling of this effect fixes the issue.
Signed-off-by: Felix Rueegg <felix.rueegg@gmail.com>
---
drivers/input/ff-memless.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
index 74c0d8c..2e06948 100644
--- a/drivers/input/ff-memless.c
+++ b/drivers/input/ff-memless.c
@@ -139,10 +139,13 @@ static void ml_schedule_timer(struct ml_device *ml)
if (!test_bit(FF_EFFECT_STARTED, &state->flags))
continue;
- if (test_bit(FF_EFFECT_PLAYING, &state->flags))
+ if (test_bit(FF_EFFECT_PLAYING, &state->flags)) {
next_at = calculate_next_time(state);
- else
+ if (next_at == now)
+ continue;
+ } else {
next_at = state->play_at;
+ }
if (time_before_eq(now, next_at) &&
(++events == 1 || time_before(next_at, earliest)))
--
1.9.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again
2014-03-02 11:35 [PATCH] input: ff-memless: don't schedule already playing effect to play again Felix Rueegg
@ 2014-03-02 13:17 ` Elias Vanderstuyft
[not found] ` <1452937.KaXPu2ynQ6@sigyn>
2014-03-02 13:37 ` Michal Malý
2014-03-04 17:07 ` Dmitry Torokhov
1 sibling, 2 replies; 6+ messages in thread
From: Elias Vanderstuyft @ 2014-03-02 13:17 UTC (permalink / raw)
To: Michal Malý; +Cc: Felix Rueegg, Dmitry Torokhov, linux-input, linux-kernel
On Sun, Mar 2, 2014 at 12:35 PM, Felix Rueegg <felix.rueegg@gmail.com> wrote:
> When an effect with zero replay length, zero replay delay
> and zero envelope attack length is uploaded, it is played and then scheduled to play
> again one timer tick later. This triggers a warning (URB submitted while
> active) in combination with the xpad driver.
>
> Skipping the rescheduling of this effect fixes the issue.
>
> Signed-off-by: Felix Rueegg <felix.rueegg@gmail.com>
> ---
> drivers/input/ff-memless.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
> index 74c0d8c..2e06948 100644
> --- a/drivers/input/ff-memless.c
> +++ b/drivers/input/ff-memless.c
> @@ -139,10 +139,13 @@ static void ml_schedule_timer(struct ml_device *ml)
> if (!test_bit(FF_EFFECT_STARTED, &state->flags))
> continue;
>
> - if (test_bit(FF_EFFECT_PLAYING, &state->flags))
> + if (test_bit(FF_EFFECT_PLAYING, &state->flags)) {
> next_at = calculate_next_time(state);
> - else
> + if (next_at == now)
> + continue;
> + } else {
> next_at = state->play_at;
> + }
>
> if (time_before_eq(now, next_at) &&
> (++events == 1 || time_before(next_at, earliest)))
> --
> 1.9.0
>
> --
@Michal: Is ff-memless-next also affected by this problem?
Elias
^ permalink raw reply [flat|nested] 6+ messages in thread[parent not found: <1452937.KaXPu2ynQ6@sigyn>]
* Fwd: [PATCH] input: ff-memless: don't schedule already playing effect to play again
[not found] ` <1452937.KaXPu2ynQ6@sigyn>
@ 2014-03-02 13:36 ` Elias Vanderstuyft
0 siblings, 0 replies; 6+ messages in thread
From: Elias Vanderstuyft @ 2014-03-02 13:36 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Felix Rueegg, linux-input, linux-kernel, Michal Malý
---------- Forwarded message ----------
From: Michal Malý <madcatxster@prifuk.cz>
Date: Sun, Mar 2, 2014 at 2:29 PM
Subject: Re: [PATCH] input: ff-memless: don't schedule already playing
effect to play again
To: Elias Vanderstuyft <elias.vds@gmail.com>
On Sunday 02 of March 2014 14:17:58 you wrote:
> On Sun, Mar 2, 2014 at 12:35 PM, Felix Rueegg
<felix.rueegg@gmail.com> wrote:
> > When an effect with zero replay length, zero replay delay
> > and zero envelope attack length is uploaded, it is played and then
> > scheduled to play again one timer tick later. This triggers a
warning
> > (URB submitted while active) in combination with the xpad driver.
> >
> > Skipping the rescheduling of this effect fixes the issue.
> >
> > Signed-off-by: Felix Rueegg <felix.rueegg@gmail.com>
> > ---
> >
> > drivers/input/ff-memless.c | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
> > index 74c0d8c..2e06948 100644
> > --- a/drivers/input/ff-memless.c
> > +++ b/drivers/input/ff-memless.c
> > @@ -139,10 +139,13 @@ static void ml_schedule_timer(struct
ml_device *ml)
> >
> > if (!test_bit(FF_EFFECT_STARTED, &state->flags))
> >
> > continue;
> >
> > - if (test_bit(FF_EFFECT_PLAYING, &state->flags))
> > + if (test_bit(FF_EFFECT_PLAYING, &state->flags)) {
> >
> > next_at = calculate_next_time(state);
> >
> > - else
> > + if (next_at == now)
> > + continue;
> > + } else {
> >
> > next_at = state->play_at;
> >
> > + }
> >
> > if (time_before_eq(now, next_at) &&
> >
> > (++events == 1 || time_before(next_at, earliest)))
> >
> > --
> > 1.9.0
> >
> > --
>
> @Michal: Is ff-memless-next also affected by this problem?
>
> Elias
I hope it's not, see mlnx_get_envelope_update_time(), this part in
particular:
/* Prevent the effect from being started twice */
if (mlnxeff->begin_at == now && mlnx_is_playing(mlnxeff))
return now - 1;
return mlnxeff->begin_at;
Michal
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again
2014-03-02 13:17 ` Elias Vanderstuyft
[not found] ` <1452937.KaXPu2ynQ6@sigyn>
@ 2014-03-02 13:37 ` Michal Malý
1 sibling, 0 replies; 6+ messages in thread
From: Michal Malý @ 2014-03-02 13:37 UTC (permalink / raw)
To: Felix Rueegg; +Cc: Dmitry Torokhov, linux-input, linux-kernel
On Sunday 02 of March 2014 14:17:58 you wrote:
> On Sun, Mar 2, 2014 at 12:35 PM, Felix Rueegg
<felix.rueegg@gmail.com> wrote:
> > When an effect with zero replay length, zero replay delay
> > and zero envelope attack length is uploaded, it is played and then
> > scheduled to play again one timer tick later. This triggers a
warning
> > (URB submitted while active) in combination with the xpad driver.
> >
> > Skipping the rescheduling of this effect fixes the issue.
> >
> > Signed-off-by: Felix Rueegg <felix.rueegg@gmail.com>
> > ---
> >
> > drivers/input/ff-memless.c | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
> > index 74c0d8c..2e06948 100644
> > --- a/drivers/input/ff-memless.c
> > +++ b/drivers/input/ff-memless.c
> > @@ -139,10 +139,13 @@ static void ml_schedule_timer(struct
ml_device *ml)
> >
> > if (!test_bit(FF_EFFECT_STARTED, &state->flags))
> >
> > continue;
> >
> > - if (test_bit(FF_EFFECT_PLAYING, &state->flags))
> > + if (test_bit(FF_EFFECT_PLAYING, &state->flags)) {
> >
> > next_at = calculate_next_time(state);
> >
> > - else
> > + if (next_at == now)
> > + continue;
> > + } else {
> >
> > next_at = state->play_at;
> >
> > + }
> >
> > if (time_before_eq(now, next_at) &&
> >
> > (++events == 1 || time_before(next_at, earliest)))
> >
> > --
> > 1.9.0
> >
> > --
>
> @Michal: Is ff-memless-next also affected by this problem?
>
> Elias
I hope it's not, see mlnx_get_envelope_update_time(), this part in
particular:
/* Prevent the effect from being started twice */
if (mlnxeff->begin_at == now && mlnx_is_playing(mlnxeff))
return now - 1;
return mlnxeff->begin_at;
Michal
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again
2014-03-02 11:35 [PATCH] input: ff-memless: don't schedule already playing effect to play again Felix Rueegg
2014-03-02 13:17 ` Elias Vanderstuyft
@ 2014-03-04 17:07 ` Dmitry Torokhov
2014-03-06 18:05 ` Felix Rueegg
1 sibling, 1 reply; 6+ messages in thread
From: Dmitry Torokhov @ 2014-03-04 17:07 UTC (permalink / raw)
To: Felix Rueegg; +Cc: linux-input, linux-kernel
Hi Felix,
On Sun, Mar 02, 2014 at 12:35:43PM +0100, Felix Rueegg wrote:
> When an effect with zero replay length, zero replay delay
> and zero envelope attack length is uploaded, it is played and then scheduled to play
> again one timer tick later. This triggers a warning (URB submitted while
> active) in combination with the xpad driver.
>
> Skipping the rescheduling of this effect fixes the issue.
Won't the same issue happen if we happen to schedule a different effect
that would start at "now" time? We should not be "dropping" the new
effect, at least not in core.
It looks to me xpad.c needs [more] love.
>
> Signed-off-by: Felix Rueegg <felix.rueegg@gmail.com>
> ---
> drivers/input/ff-memless.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
> index 74c0d8c..2e06948 100644
> --- a/drivers/input/ff-memless.c
> +++ b/drivers/input/ff-memless.c
> @@ -139,10 +139,13 @@ static void ml_schedule_timer(struct ml_device *ml)
> if (!test_bit(FF_EFFECT_STARTED, &state->flags))
> continue;
>
> - if (test_bit(FF_EFFECT_PLAYING, &state->flags))
> + if (test_bit(FF_EFFECT_PLAYING, &state->flags)) {
> next_at = calculate_next_time(state);
> - else
> + if (next_at == now)
> + continue;
> + } else {
> next_at = state->play_at;
> + }
>
> if (time_before_eq(now, next_at) &&
> (++events == 1 || time_before(next_at, earliest)))
> --
> 1.9.0
>
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again
2014-03-04 17:07 ` Dmitry Torokhov
@ 2014-03-06 18:05 ` Felix Rueegg
0 siblings, 0 replies; 6+ messages in thread
From: Felix Rueegg @ 2014-03-06 18:05 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
Hi Dmitry,
On 03/04/2014 06:07 PM, Dmitry Torokhov wrote:
> Hi Felix,
>
> On Sun, Mar 02, 2014 at 12:35:43PM +0100, Felix Rueegg wrote:
>> When an effect with zero replay length, zero replay delay
>> and zero envelope attack length is uploaded, it is played and then scheduled to play
>> again one timer tick later. This triggers a warning (URB submitted while
>> active) in combination with the xpad driver.
>>
>> Skipping the rescheduling of this effect fixes the issue.
> Won't the same issue happen if we happen to schedule a different effect
> that would start at "now" time? We should not be "dropping" the new
> effect, at least not in core.
I can confirm this. It also happens sometimes with an effect that has a
length and a replay count greater than one at the time, when the effect
ends and restarts again.
> It looks to me xpad.c needs [more] love.
I agree and will try to come up with a fix for the xpad driver.
>> Signed-off-by: Felix Rueegg <felix.rueegg@gmail.com>
>> ---
>> drivers/input/ff-memless.c | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
>> index 74c0d8c..2e06948 100644
>> --- a/drivers/input/ff-memless.c
>> +++ b/drivers/input/ff-memless.c
>> @@ -139,10 +139,13 @@ static void ml_schedule_timer(struct ml_device *ml)
>> if (!test_bit(FF_EFFECT_STARTED, &state->flags))
>> continue;
>>
>> - if (test_bit(FF_EFFECT_PLAYING, &state->flags))
>> + if (test_bit(FF_EFFECT_PLAYING, &state->flags)) {
>> next_at = calculate_next_time(state);
>> - else
>> + if (next_at == now)
>> + continue;
>> + } else {
>> next_at = state->play_at;
>> + }
>>
>> if (time_before_eq(now, next_at) &&
>> (++events == 1 || time_before(next_at, earliest)))
>> --
>> 1.9.0
>>
> Thanks.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-03-06 18:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-02 11:35 [PATCH] input: ff-memless: don't schedule already playing effect to play again Felix Rueegg
2014-03-02 13:17 ` Elias Vanderstuyft
[not found] ` <1452937.KaXPu2ynQ6@sigyn>
2014-03-02 13:36 ` Fwd: " Elias Vanderstuyft
2014-03-02 13:37 ` Michal Malý
2014-03-04 17:07 ` Dmitry Torokhov
2014-03-06 18:05 ` Felix Rueegg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).