[PATCH libinput 2/2] evdev-mt-touchpad: Switch to smooth simple acceleration code from filter.c

[Peter Hutterer]

On Tue, Jul 01, 2014 at 02:32:56PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 07/01/2014 06:33 AM, Peter Hutterer wrote:
> 
> <snip>
> 
> > The idea is interesting. Indeed on the T440 with a relatively large and
> > square-ish touchpad, this is much better now. On the x220 with a small
> > 16:10 ratio touchpad it's better but not yet good. It feels like the pointer
> > acceleration kicks in too quickly and too strongly, so there is no middle
> > ground: movement is either slow and precise or it overshoots the target.
> > 
> > Both have the same scaling factor (0.24) but due to the resolution, the
> > values are oviously quite different. I played with adjusting the
> > accel/threshold parameters on both and both touchpads can be made to feel
> > good by adjusting the threshold a bit.
> 
> Which thresholds did you come up with for either ? Did you do:
> "xset m 1 10" before testing ? Talking about that a few days ago you send
> me a private mail with some lines to add to xf86-input-libinput to make it
> disable X own's accel automatically, but I've already deleted that mail
> before actually putting the 2 lines to use, can you give me those 2
> lines again ?

Yes, I disabled accel in the X driver, but for quick testing I recommend
the event-gui tool. It starts quicker after a rebuild over a X session
restart and with the x accel disabled the pointer moves identical to the X
pointer anyway.

For reference, the xf86-input-libinput commit was:
https://github.com/whot/xf86-input-libinput/commit/6a6946235979f51169f9256414eb24226cf6f1bc

> > That doesn't bode well for the idea of "small touchpads should move the
> > pointer move", but I don't know how to measure this generically or even
> > objectively.
> 
> I think the best we can do is just try to come up with something which feels
> ok to us with the default accel settings (note we may use different default
> accel settings for touchpads) everywhere. There is no hard science involved
> here, only lots of handwaving.

Yeah. Getting the default accel right is important but we may not actually
get there with the current generic approach. If the touchpads are that
different, we can add model/vendor specific acceleration profiles or
defaults. We have that in the synaptics driver and while it hasn't really
been maintained much there are arguments for it. just something to keep in
mind.

Cheers,
   Peter

> 
> I'm going to the local hackerspace tonight, I'm currently preparing a
> usb disk with rawhide + libinput + xf86-input-libinput on there, and I'll
> try to test the new accel code on as much different model laptops as
> possible.
> 
> > how did you come up with 1200 for DEFAULT_SIZE_ACCEL_NUMERATOR?
> 
> I went with a value which felt good on the 2 machines I've been testing on
> sofar.
> 
> > I found a
> > value of 800 to be good enough by default on both, but that's
> > going to change with every touchpad. What touchpads did you test this on?
> 
> On the T440s (large synaptics touchpad) and a Latitude E6430 (medium size
> alps). I mostly fine tuned the value on the alps, since that one is the
> hardest to get right (the touchpad is not the best in the world, so its
> more sensitive to these kinda things).
> 
> > What about using the resolution to normalize movements based on physical
> > movement where possible and falling back to this method where the resolution
> > is set?
> 
> I think that that is a good idea, I'm not sure about the extra speed for
> small touchpad things myself either, this will just give us a constant
> speed per cm moved on touchpads advertising a resolution, which seems like
> a good starting point.
> 
> > Talking about the patch:
> > What's confusing about the comment is that you talk about leaving resolution
> > out, right after we calculate the scaling coefficients based on the
> > resolution. Which of course only serves to correct uneven resolutions, but
> > still, it confused me. I'd like to see this reworded somehow.
> 
> Since we're switching to using resolution by default I'm going to completely
> axe the comment in question and put in a much simpler comment instead.
> 
> I'll send a v2 of this patch soon-ish.
> 
> Regards,
> 
> Hans