Honestly, the purpose of this timer baffles me a bit. AFAICT, it should never fire.<div><br></div><div>The comment says:</div><div><span style="border-collapse:collapse;font-family:sans-serif;font-size:13px"><pre style="padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">
<code>"to create fluid edge motion, call back 'soon' even in the absence of new hardware events"</code></pre></span></div><div><br></div><div>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.</div>
<div><br></div><div>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 <span class="Apple-style-span" style="border-collapse: collapse; font-family: monospace; font-size: 13px; white-space: pre; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px; ">timerFunc</span> copies previous <span class="Apple-style-span" style="border-collapse: collapse; font-family: monospace; font-size: 13px; white-space: pre; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px; ">priv->hwState</span>), what this means is, once fired, this timer will keep firing forever.</div>
<div><br></div><div>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.</div>
<div>These packets are recognized as "!insidearea", which resets <span class="Apple-style-span" style="border-collapse: collapse; font-family: monospace; font-size: 13px; white-space: pre; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px; ">priv->count_packet_finger</span> and therefore doesn't schedule the edge_motion timer, effectively cancelling it.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div><br></div><div><div class="gmail_quote">On Tue, Mar 1, 2011 at 9:12 AM, Peter Hutterer <span dir="ltr"><<a href="mailto:peter.hutterer@who-t.net" target="_blank">peter.hutterer@who-t.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div>On Mon, Feb 28, 2011 at 08:56:27PM +0800, Daniel Kurtz wrote:<br>
> Some Synaptics image sensors report samples at less than 80 Samples/sec.<br>
> Thus, the inter-sample gap is longer than 13 ms (more like 17-25 ms).<br>
><br>
> With a 13ms timeout, every sample was processed twice:<br>
> 1) Once when ReadHwState() returned valid data.<br>
> 2) 13ms later, when the scheduled timer would expire.<br>
><br>
> The value 50ms is chosen arbitrarily higher than the expected slowest<br>
> trackpad reporting interval, but short enough not to be noticeable by<br>
> a human user.<br>
><br>
> Signed-off-by: Daniel Kurtz <<a href="mailto:djkurtz@google.com" target="_blank">djkurtz@google.com</a>><br>
> ---<br>
> src/synaptics.c | 2 +-<br>
> 1 files changed, 1 insertions(+), 1 deletions(-)<br>
><br>
> diff --git a/src/synaptics.c b/src/synaptics.c<br>
> index 56ce725..0b2d7a1 100644<br>
> --- a/src/synaptics.c<br>
> +++ b/src/synaptics.c<br>
> @@ -1870,7 +1870,7 @@ ComputeDeltas(SynapticsPrivate *priv, const struct SynapticsHwState *hw,<br>
><br>
> /* to create fluid edge motion, call back 'soon'<br>
> * even in the absence of new hardware events */<br>
> - delay = MIN(delay, 13);<br>
> + delay = MIN(delay, 50);<br>
><br>
> if (priv->count_packet_finger <= 3) /* min. 3 packets, see get_delta() */<br>
> goto skip; /* skip the lot */<br>
> --<br>
> 1.7.3.1<br>
<br>
</div></div>I wonder - wouldn't the better fix be to cancel the timer if the data was<br>
processed or if new data would come in?<br>
<br>
Cheers,<br>
<font color="#888888"> Peter<br>
</font></blockquote></div><br></div>