[RFC] libinput configuration interface

[Peter Hutterer]

hey, sorry about the delay, I got moved to other stuff for a while and only
now just picked up libinput again.

On Sat, Feb 22, 2014 at 03:33:26PM +0600, Alexander E. Patrakov wrote:
> 2014-02-21 5:26 GMT+06:00 Peter Hutterer <peter.hutterer at who-t.net>:
> > On Fri, Feb 21, 2014 at 01:29:05AM +0600, Alexander E. Patrakov wrote:
> >> Vertical two-finger scrolling works, but is way too sensitive both
> >> with constant deceleration 1.0 and with 0.3.
> >
> > that's a xf86-input-libinput bug, Benjamin fixed that but I forgot to
> > push. 761603d..bee8989 now, please re-test that.
> 
> The speed is now fixed indeed, but scrolling is now subject to the
> same "dirty mouse" bug. See the "badscroll.rec" file in the attached
> archive. It contains two scoll gestures - one down, and one up. The
> driver has picked up only the beginning of the up-scroll (i.e. the
> chromium window was not scrolled as far as I wanted, even though I
> continued moving both fingers).
 
I've looked at this and I think I know what you mean. I get a massive jump
down first, then a slight up only. Looking at the ./tools/event-debug output
from libinput it looks like the coordinates for downward scroll are massive
too (between 10 and 48), the upwards ones are hanging around the -3 to -4
mark. That would explain the different scrolling. however, that matches the
recordings.

I think what may be the problem here is the motion averaging between the
fingers. the driver currently takes the changed touchpoints and averages the
motion between the two for the actual scroll distance. this may slow down
slow scrolls, I'll need to run some tests on this.

> >> Tapping and tap-and-drag are not usable. They require not tapping,
> >> but knocking with force. So this points to the driver being
> >> "miscalibrated" on the pressure axis. Can this also be the reason of
> >> the low x/y sensitivity and "dirty mouse" feeling?
> >
> > that's a bit odd. I'd like to see an evemu-record output from that then.
> > Currently I ignore pressure completely, so any touch should be detected.
> 
> Actually the first tap after the server start is detected reliably.
> The problem only affects other taps. See the file "tap-libinput.rec"
> in the attached archive.
 
I had a look at the recording files, mainly with the event-debug tools but
I'm struggingling to see the same issues. the tap recording has 6 touches,
some of which are taps, others are moves. I can spot three taps in there,
one in the middle somewhere, two towards the end and that seems to match the
recordings.

Cheers,
   Peter