Pointer glide patch for Input/synaptics

[Peter Hutterer]

On Sat, Jan 24, 2009 at 08:51:00PM +0000, Dylan McCall wrote:
> > 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.
 
> 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

I just pushed the float patches to the synaptics driver, please update your
patch accordingly to make testing easier.

> ...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.

Can you provide a reference for that?
The corners are easiest to reach anyway, as the pointer movement will be
clipped at the screen edges. So with the glide patch, all that changes is the
amount of movement required to reach the edges.
 
> 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.

Touchscreens and touchpads are not the same. Touchscreens are direct-touch
interfaces, touchpads are indirect interfaces - like the common mouse.
The assumption that interaction methods are the same on both devices is
flawed. Even more so as direct-touch interfaces implement kinetics on
*objects*, not on the pointer (which should ideally be invisible anyway). 

> 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. 

Kinetic scrolling is kinetics applied to virtual objects on the screen, not to
the pointer. Huge difference there.

> 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

It's not about performance, it's about maintainability. In the end, any code
in the driver has to be maintained, and dragging features around just for fun
is not much of the same.
We don't have a lot of developers, so code maintainance comes at a high cost.

I do encourage you to rewrite the patch so that distributions can pick it up
and use it. I'm still hesitant about putting it into the upstream driver until
you provide some feedback from users and we can see that the feature is
actually being used.
 
> 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?

I don't know what you mean by extended input device data.

> 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?

Probably been fixed. There's been a few patches going into synaptics over the
last few months.

Cheers,
  Peter