On 03/01/2011 03:12 AM, Peter Hutterer wrote: > On Tue, Mar 01, 2011 at 09:40:38AM +0800, Daniel Kurtz wrote: >> Honestly, the purpose of this timer baffles me a bit. AFAICT, it should >> never fire. > > note that this timer has been present for years now while large parts of the > driver evolved around it. it is quite possible that it has outlived its > original purpose. > >> The comment says: >> >> "to create fluid edge motion, call back 'soon' even in the absence of >> new hardware events" > > this comment was only added Feb 21 this year and replaced the old "WTF? > what's with 13?" comment :) Oops - I'm sorry if my analysis was not correct. I assumed one cannot rely on further events if there is no actual motion.
> you could easily add a field to hwState to indicate if it's a timer event or > not. but I think that just removing this timer may be the best approach. > If it really breaks on some pads we should have people yelling at us quite > quickly. People having the right non-default settings, that is... Still, +1 for the real/synthetic flag approach. > > My suspicion is that the kernel filters for us - the backends that may be > affected are the non-evdev ones but I have no setups to test these. > > Cheers, > Peter > >> On Tue, Mar 1, 2011 at 9:12 AM, Peter Hutterer >> <[email protected]>wrote: >> >>> On Mon, Feb 28, 2011 at 08:56:27PM +0800, Daniel Kurtz wrote: >>>> Some Synaptics image sensors report samples at less than 80 Samples/sec. >>>> Thus, the inter-sample gap is longer than 13 ms (more like 17-25 ms). >>>> >>>> With a 13ms timeout, every sample was processed twice: >>>> 1) Once when ReadHwState() returned valid data. >>>> 2) 13ms later, when the scheduled timer would expire. >>>> >>>> The value 50ms is chosen arbitrarily higher than the expected slowest >>>> trackpad reporting interval, but short enough not to be noticeable by >>>> a human user. >>>> >>>> Signed-off-by: Daniel Kurtz <[email protected]> >>>> --- >>>> src/synaptics.c | 2 +- >>>> 1 files changed, 1 insertions(+), 1 deletions(-) >>>> >>>> diff --git a/src/synaptics.c b/src/synaptics.c >>>> index 56ce725..0b2d7a1 100644 >>>> --- a/src/synaptics.c >>>> +++ b/src/synaptics.c >>>> @@ -1870,7 +1870,7 @@ ComputeDeltas(SynapticsPrivate *priv, const struct >>> SynapticsHwState *hw, >>>> >>>> /* to create fluid edge motion, call back 'soon' >>>> * even in the absence of new hardware events */ >>>> - delay = MIN(delay, 13); >>>> + delay = MIN(delay, 50); >>>> >>>> if (priv->count_packet_finger <= 3) /* min. 3 packets, see >>> get_delta() */ >>>> goto skip; /* skip the lot */ >>>> -- >>>> 1.7.3.1 >>> >>> I wonder - wouldn't the better fix be to cancel the timer if the data was >>> processed or if new data would come in? >>> >>> Cheers, >>> Peter >>> > _______________________________________________ > [email protected]: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
