Hi Dmitry > I wonder if we can't simply leave the FF_EFFECT_PLAYING flag as is > when updating an effect. Although we still may skip over them in > ml_get_combo_effect() is play_at is in the future. Should we > immediately stop updated effects? You can not stop the effect for update with zero delay. This would create on->off->on pulse in the force during each update for applications which are using a single continuously updated force. Be it rumble for applications ported from xinput style api or constant for some racing simulations. Stopping effect for update with non-zero delay would actually improve consistency. Currently the behavior in this case depends on if there is another force of the same type currently playing. If there is none, hw force is not updated and remains at its last state until the new play_at time. If there is second effect which will trigger hw update then the first effect effectively stops when that happens. The downside of change in this behavior after such long time is that there might be applications knowingly or unknowingly relying on it. I think that changing the stop operation to always set FF_EFFECT_ABORTING flag together with setting play_at to jiffies (to bypass the check in ml_get_combo_effect) regardless of the playing state of started effect might fix the original issue. Improving the consistency in the non-zero delay case would likely require a different flag which would cause the timer to be scheduled for now, bypass the play_at check and not mix the force in if the play_at check would otherwise fail. With regards Jiri
