On Jun 10 14:43, Peter Hutterer wrote: > On Fri, Jun 05, 2015 at 04:22:51PM -0600, Wade Berrier wrote: > > Hello, > > > > I'm running libinput 0.17 on Fedora 22 (compiled and installed the > > rawhide src.rpm) on an Acer c720 chromebook. The observations below > > also apply to 0.15 that shipped with the distro, but I upgraded to see > > if it changed the behavior. > > just fwiw, I'm pushing out updated packages on an almost daily basis (f22 > and rawhide) and ptraccel is the main things being tweaked at the moment. > > > The trackpad doesn't quite "feel right". Here's some of the main > > observations compared to when using the trackpad with ChromeOS and/or > > the cmt driver: > > > > 1. the pointer is very "fidgety". Relatively small movements move the > > pointer around quite a bit. If I adjust the pointer speed to the minimum > > (using "Mouse & Touchpad" gui) these small controlled movements seem > > much more accurate. But, then it takes several "swipes" to move the > > pointer to the other side of the screen. > > > > 2. at first it seemed that no matter what "pointer speed" setting I > > tried, finger distance always covered the same amount of screen > > distance, no matter the finger velocity. ie: no acceleration > > handling. I came across [1] and realized that wasn't the case. > > After additional tinkering, I was able to affect screen distance > > with finger speed, but it seemed very difficult to get into that > > state/window. > > Note: the below is gut feeling at this point: > I think our biggest problem with touchpad acceleration is that we get too > quickly into full acceleleration, so the gap between no acceleration and > full acceleration is too narrow. > if you always hit full acceleration, then you wouldn't notice the difference > and it would feel like constant acceleration.
I logged the following bugs for these: https://bugzilla.redhat.com/show_bug.cgi?id=1230459 https://bugzilla.redhat.com/show_bug.cgi?id=1230462 I hope they are useful. It still seems a little subjective/arbitrary, but they are there, fwiw. Let me know if I can provide better information, recordings, etc... > > > In short, the lowest pointer speed feels natural in localized > > scenarios requiring high precision (ie: clicking on tiny stuff). But, > > when swiping faster to travel to the other side of the screen, a 40% > > setting seems to "feel" about right. It's interesting that ChromeOS > > gets away with not even having a pointer speed adjustment. > > note that chromeos afaik only needs to support two touchpads, which makes > the job a bit easier. I'm not sure how many different touchpads they have to support, but they sure have a lot of finely tuned configurations: https://github.com/hugegreenbug/xf86-input-cmt/tree/master/xorg-conf > > > 3. the pointer moves around when doing "hard clicks". Both on the way > > down and the way up. It seems like ChromeOS "locks" the pointer in > > place during this case. Without this, my 5 year old son is unable > > to hard click a button, whereas he's able to on ChromeOS. Also > > interesting, is that in ChromeOS I can roll my fingertip in circles > > and the pointer barely, if at all, moves. So, I guess this is an > > issue whether I'm clicking or not. > > file a bug for this please, with an evemu recording for one of these moving > clicks. we have that feature in libinput, but you're clearly getting outside > of it's boundaries. Filed as https://bugzilla.redhat.com/show_bug.cgi?id=1230441 > > > 4. I get spurious pointer movement and clicks from my right palm while my > > hands are in typing position. The feature of disabling the mouse > > while typing partially helps. Also, the trackpad isn't centered > > between my hands on the c720, possibly making it only happen with my > > right hand. On ChromeOS, I can tap my palm all over the pad and > > will get an occasional click but no pointer movement. > > same here, please file a bug with a couple of emu recordings. there's a plan > for thumb detection (which would also detect palms) but it's not > there yet. Filed as https://bugzilla.redhat.com/show_bug.cgi?id=1230446 > > > As an aside, it sounds like the mouse team at google pressure > > calibrates [2] their hardware. Is libinput normalizing pressure in > > addition to dpi? If so, does the hardware database also include > > information for device specific pressure calibration? > > libinput doesn't use pressure on touchpads yet. it's somewhere on the > list, but so far we've gotten away without having to worry about it > :) I imagine this will become much more relevant at some point: https://support.apple.com/en-us/HT204352 (I must admit, I tried this touchpad at the apple store and surprisingly it feels incredibly intuitive, and I'm not a mac user.) > > > > > I realize this is all highly subjective to muscle memory and personal > > preference, but I think it can be useful to compare to the excellent > > experience that the ChromeOS driver offers. > > > > So, where do I go from here? Are my observations specific to the > > c720? Is there something I can try out or tweak? If it were easy to > > use the xf86-cmt driver on fedora [3] I probably would, but given > > wayland will be using libinput it would be nice to get libinput > > working nicely on this trackpad. > > as above, 3) is definitely a bug, 4) is a todo, 2 is being worked on, 1) as > well but that too would likely benefit from a bug+evemu recording of such a > small movement. these touchpads have a comparatively low resolution, so I > wonder if we have a simple bug there. > The response and feedback is much appreciated. Thanks, Wade _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
