Honestly, the purpose of this timer baffles me a bit. AFAICT, it should never fire.
The comment says: "to create fluid edge motion, call back 'soon' even in the absence of new hardware events" However, my understanding is that edge motion occurs when a drag or move hits an edge, but the finger stays in contact with the pad. Thus, there should always still be hardware events during an edge motion. This timer, instead, should only fire after the finger is raised immediately after a valid motion packet (a hardware sample that generated a delta resulting in pointer motion). Actually, since there is no way of distinguishing between timer-events and hardware-events (since timerFunc copies previous priv->hwState), what this means is, once fired, this timer will keep firing forever. However, at least on the trackpads that I have tested, this doesn't happen for a very different reason. When the finger is lifted from the pad, the touchpad/kernel-driver doesn't immediately stop sending packets. Instead, it sends about 1 second worth of dummy "x=0,y=0,z=0..." packets at regular intervals. These packets are recognized as "!insidearea", which resets priv->count_packet_finger and therefore doesn't schedule the edge_motion timer, effectively cancelling it. The only time this timer actual fires, then, is in this case that I am trying to fix - when it fires in between touchpad hardware samples because the touchpad generates samples slower than 13 ms apart. 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
