Pointer glide patch for Input/synaptics

[Matt Helsley]

On Thu, 2009-01-22 at 08:28 -0800, Dylan McCall wrote:
> Hello!
> 
> I'm just wondering what people think of the little "pointer glide" thing
> I submitted. Here would be a better place for discussion than on
> bugzilla, if anyone is interested :)
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=19525
> 
> The mouse is a successful input technique because the physical device
> makes sense. It "feels" like the mouse pointer on the screen and obeys
> the laws of physics if someone throws it (not that anyone would do
> that). The important part is that the user controls the pointer directly

<snip>

> This is all achieved through ridiculously primitive physics, of course!
> I have the pointer continuing along its path when the finger is
> released, slowed down gradually by a set friction and capped with a
> maximum speed to avoid anything weird happening. The pointer glide
> behaviour only gets in the way if one is expecting it, and defaults to
> being turned off.

<snip>

I really dislike touchpads so I won't comment on whether glide is an
improvement or not. However, I do like "real-time" physics simulation
code so here are a few thoughts:

Restricting pointer_glide_friction to a positive value would ensure that
the pointer can never move opposite the direction of the flick.

Speed should never go negative. That would mean the pointer is moving in
the opposite direction.

There is no need to check if speed exceeds max_speed more than once
since friction should damp speed until it reaches near-zero.

Never test for equality with 0 when doing floating point math. Test the
absolute value of the speed against a suitably-small constant (often
called "epsilon").

The complex math can be avoided if you don't use speed and angle (polar
coordinates) to store the velocity. Rectangular coordinate vector math
is simpler for this task. Then instead of testing for non-zero speed you
can do:

if (fabs(velocity_x) > epsilon || fabs(velocity_y) > epsilon)
	/* still moving */
else
	/* stopped */

If hw->millis value "overflows" then the pointer could still move in the
opposite direction -- though it would take a specific set of
circumstances and may not be very noticeable.

Cheers,
	-Matt Helsley