On 04/18/2012 11:46 PM, Peter Hutterer wrote:
> The eventcomm backend takes the timestamp from the kernel, but the timer
> uses the timer's "now". This timestamp may be later than the one from the
> next event we read from the kernel, causing a negative dtime in get_delta()
> and a cursor jump by (unsigned int)(eventtime - timer_time).
> 
> Ensure that the new event's timestamp is at least the last used one.
> 
> X.Org Bug 48777 <http://bugs.freedesktop.org/show_bug.cgi?id=48777>
> 
> Signed-off-by: Peter Hutterer <[email protected]>
> ---
>  src/synaptics.c |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/synaptics.c b/src/synaptics.c
> index 350567d..3309e90 100644
> --- a/src/synaptics.c
> +++ b/src/synaptics.c
> @@ -1635,6 +1635,10 @@ ReadInput(InputInfoPtr pInfo)
>           hw->cumulative_dy = priv->hwState->cumulative_dy;
>       }
>  
> +        /* timer may cause actual events to lag behind (#48777) */
> +        if (priv->hwState->millis > hw->millis)
> +            hw->millis = priv->hwState->millis;
> +
>       SynapticsCopyHwState(priv->hwState, hw);
>       delay = HandleState(pInfo, hw, hw->millis, FALSE);
>       newDelay = TRUE;

There are two other ways I can think of to resolve this:

* Test for negative dtime in get_delta()
* Do priv->hwState->millis = hw->millis instead

However, it looks like there are more places than just get_delta() that
would need to be fixed for alternative 1, and likewise we would need to
ensure that the non-monotonic timestamps are ok everywhere for
alternative 2. I think the proposed solution makes the most sense.

Reviewed-by: Chase Douglas <[email protected]>
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to