Pointer glide patch for Input/synaptics

[Dylan McCall]

> Can you explain what reasonable defaults one should use for the friction?
> The default ones (I just applied the patch here) don't really make sense to
> me. If anything, they make the touchpad harder to use as there's a high chance
> that the pointer keeps moving after I have released over a button and I miss
> the target.
> 
> Cheers,
>   Peter

Thanks for the thoughts, Peter!
I agree, my defaults are sadly neglected. I'm hoping that over time some
really good ones may emerge. There's a lot those two variables can do.

(One recent realization that could help: the driver knows when a finger
is a few mm away from the touchpad, so that could be used to apply some
extra friction. Could also be total feature creep).

Here is what I have now for configuration:

PointerGlide            = 1
PointerGlideFriction    = 0.006
PointerGlideMaxSpeed    = 5

...Allowing some more flexibility. High max speed and high friction
should get the slower moving pointers to stop nice and quickly so issues
with pressing buttons are less of a problem.

I have been pestering my friends and family with this for a little while
now and they seem mostly positive about the idea, but I haven't had the
chance to do much real-world testing except on myself. (And I am
definitely not a real-world user).

This has a nice effect for Fitt's law stuff. Fitt's law points to an
idea that the user should be able to carelessly slam the mouse pointer
to the top of the screen in order to press an important button like the
main menu or the window switcher. The touchpad doesn't really allow this
(maybe fancier pointer acceleration would help), but with my tweak the
user can safely "flick" the pointer to a corner of the screen.

As for justification, I think we have seen a very cohesive movement
towards this type of interaction for touch screen interfaces. Kinetic
scrolling is a must-have for any such thing. It's ultimately the same
difference between kinetic scrolling and its predecessor as is moving
the pointer with a touch pad, and even the same physical interface since
both involve running one's finger on a touch-sensitive surface.

I don't have ready proof that one method is superior to another.
However, users consistently love kinetic scrolling because it lets them
traverse long lists quickly, with the ability to stop on a dime and
control scrolling speed naturally. They usually don't need to do repeat
movements as we had with the classic push to scroll functionality, which
is roughly equivalent to touch pads right now. Granted, it's difficult
to aim at something in particular. This is usually overcome by having a
predictable speed (and I think there may be a trick to the friction
stuff that I don't quite have here).

As for feature creep, I made sure to implement this whole thing inside
of a single If statement, so the performance hit when PointerGlide=0 is
similar to a fly impacting the Earth. I put it right below circular
scrolling :P

I agree, though, it's silly how much stuff is in the driver. I'm not an
X person, but would extended input device data help? I guess that's
usable for a higher level touchpad tweeking daemon, which would Hugely
benefit by being closer to a specific desktop environment / user
interface toolkit, and by being able to support different input devices
that provide similar information.
I believe this driver provides the relevant info through that path...
right?

Bye,
-Dylan

PS: One other little observation: I was originally running the Synaptics
driver in Ubuntu's repositories (with some patches by Debian). I had an
issue where the pointer would leap to a corner of the screen. I'd blamed
it on my patch, but now I am running the driver from git and the problem
is nonexistent. Does anyone by chance know if that behaviour was fixed
in the last few months, or is this maybe a problem on Debian's end?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20090124/c67f9076/attachment.pgp>