[RFC] libinput configuration interface

[Peter Hutterer]

On Fri, Feb 21, 2014 at 01:29:05AM +0600, Alexander E. Patrakov wrote:
> 20.02.2014 12:21, I wrote:
> >20.02.2014 11:14, Peter Hutterer wrote:
> >>On Wed, Feb 19, 2014 at 11:55:28AM +0600, Alexander E. Patrakov wrote:
> >>> From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd
> >>>say that it doesn't solve the whole problem. Here is what goes wrong
> >>>with the old synaptics driver by default and can be worked around
> >>>with AreaBottomEdge.
> >>>
> >>>         Option "SoftButtonAreas" "4360 0 4000 0 2880 4359 3500 0"
> >>>         Option "AreaBottomEdge" "3500"
> >>>
> >>>1. I move the right-hand index finger on the touchpad, thus moving
> >>>the pointer to the place where I want to click.
> >>>
> >>>2. I place the left-hand index finger into the virtual-button area,
> >>>while still keeping the right finger on the touchpad. I cannot
> >>>remove the right-hand finger: if I do that, while the contact area
> >>>shrinks, its center also moves, and the driver picks that up.
> >>>
> >>>3. As I increase the pressure on the left-hand finger until the
> >>>touchpad clicks, the contact area increases. Unfortunately, its
> >>>center moves, too, and this can accumulate to ~2-3 pixels until it
> >>>clicks.
> >>>
> >>>The important point is that the bad thing happens before the
> >>>hardware button click, so the quoted solution totally misses the
> >>>point.
> >>>
> >>>So we need something, either a sledgehammer solution in the form of
> >>>ignoring all motion in the virtual button area (but that would break
> >>>Sony Vaio Duo 13 because the only usable height of the virtual
> >>>button area is 100% there), or some very good filter that pays
> 
> >>couple of comments here:
> >>2 is a synaptics bug that should really be fixed, the driver shouldn't be
> >>that sensible - in fact there's probably something that can be done about
> >>making the driver more sensible while the finger is moving and less
> >>sensible
> >>while the finger is still (just an idea, may not work for small
> >>movements). there is also the option of using pressure to counteract
> >>movements, i.e. a pressure change will increase the hysteresis to avoid
> >>erroneous movements. If you have that many issues with the Sony, I really
> >>recommend looking at the evdev-mt-touchpad patches I sent to this list,
> >>it'll allow for things like that relatively simple.
> >
> >OK, I will build this on my laptop from git later today.
> 
> Just did this, but have not looked at the code yet. Tested with
> xf86-input-libinput, thus had no chance to configure anything
> specific to libinput. If this has any chance of yielding different
> results, I will retest with Weston on Saturday.

libinput currently exposes no configuration interfaces, so the only
differences you may see is in pointer acceleration.

> Software versions:
> 
>  * mtdev 1.1.4 (Gentoo)
>  * xorg-server 1.15.0 (Gentoo)
>  * libevdev from git, cf70d0
>  * libinput from git, 128f98 + your 19 patches
>  * xf86-input-libinput from git, 761603
> 
> Hardware: Sony VAIO Z23A4R, the touchpad identifies itself as follows:
> 
> I: Bus=0011 Vendor=0002 Product=0007 Version=01b1
> N: Name="SynPS/2 Synaptics TouchPad"
> P: Phys=isa0060/serio1/input0
> S: Sysfs=/devices/platform/i8042/serio1/input/input4
> U: Uniq=
> H: Handlers=mouse0 event3
> B: PROP=5
> B: EV=b
> B: KEY=e520 10000 0 0 0 0
> B: ABS=660800011000003
> 
> Pointer movement works, but it is too slow by default on this
> laptop. That is, a VERY quick swipe (not expected during normal work
> and even during games) from left to right is just enough to move the
> pointer across the entire screen (1920x1080). Setting constant
> deceleration to 0.3 or 0.4 makes it more usable in terms of speed,
> but this might be my personal preference, and I am not sure if the
> constant deceleration is the correct knob here.

I have not yet looked into pointer-accel fine-tuning on the touchpad or in
xf86-input-libinput. What you're seeing is quite simliar to what I have here
- it's slow but not unusable. Sorry, just haven't focused on that yet by any
help would be appreciated.

I don't think deceleration is the right nob here, but I can't remember what
you need to tweak. Generally I try not to touch constant deceleration unless
the device is a high-resolution device that sends way too many events. If
you need to use a value 0..1 for CD then you're effectively using it to
speed things up, the term "deceleration" should hint that this may not work
perfectly :)

> With the default constant deceleration (1.0), pointer movement is
> very precise. It follows the finger equally well in all parts of the
> touchpad and in all directions, as expected. I get no misplaced
> clicks.
> 
> With constant deceleration 0.3, this is not true. It works better in
> the central part of the touchpad, but, when crossing the physical
> border between the area for pointer movement (which is rough) and
> the area for virtual buttons (which is smooth), it starts to behave
> like a dirty mechanical mouse. Here is what I mean by that: hard to
> move the cursor diagonally (i.e. there is a strong preference
> towards horizontal or vertical movements), and the motion is uneven
> if I move the finger slowly. The same applies to the top part of the
> touchpad, although there is no sharp line where this appears.
> 
> In both cases, there is no spurious pointer movement when putting
> the finger on the touchpad or removing it. I.e., points 2 and 3 are
> somehow already dealt with.
> 
> 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.

> Clicking works. If there are two fingers on the touchpad at the time
> of clicking, it registers a right-click. As the touchpad cannot
> track more than two touches, three-finger gestures don't work. OTOH,
> I have read Documentation/input/multi-touch-protocol.txt: "Some
> devices identify and/or track more contacts than they can report to
> the driver." I have not yet tested whether this applies to my
> touchpad, and whether it uses BTN_TOOL_TRIPLETAP.

run evtest or evemu-record against the device, that'll tell you. Note that I
haven't enabled the fake touch emulation for those devices yet, right now
BTN_TOOL* is only treated as a touch on single-touch devices.
so right now, you only get up to ABS_MT_SLOT maximum touchpoints.

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

> Can I provide any objective data that would allow better sensitivity
> calibration by default on this device?

Touchpad data is always subjective :) it depends on finger size,
conductivity and a whole bunch of other factors. what does help though is
having evemu recordings of certain events. They may still be subjective but
they're reproducible, allowing us to fine-tune based on a specific event
sequence and then go from there.

e.g. you can take a recording fo an example one-finger tap and then make
sure that that always produces a tap event. if you build up a database of
these events, you can cover events quite well for a multitude of devices and
users.

Cheers,
   Peter