> 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?
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
