Stop coasting when two-finger scroll begins

There is currently a problem that can lead the coasting to continue while scrolling in a particular situation :
with
 Option "VertTwoFingerScroll" "on"
 Option "CornerCoasting" "0"
 Option "CoastingSpeed" "10"
 Option "CoastingFriction" "50"
 Option "CornerCoasting" "0"
If you scroll down with two finger then raise a finger, coasting will start. But if you put down that finger and try to
scroll up, the inertia will still scroll down while you scroll up. This can look like a very particular situation, but
happens to me often while scrolling in a big document.

This (awfully simple) patch stop coasting when detecting two-finger scroll.

Signed-off-by: Pierre Lulé <pierre@lule.fr>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fix coasting friction

As a result of commit 5a1612d4496b51682c9043aa064025c545249de6, coasting speed
was bumped up to a different scale by removing the divisor during the
calculation of initial coasting speed. This caused coasting friction to have
little to no effect, resulting in coasting that lasted virtually forever using
the default coasting friction value of 50.

This patch multiplies the scroll_dist_{horiz,vert} which was previously used as
a divisor for initial coasting speed to the coasting friction before deducting
it at each step, thus bringing coasting friction back under control.

Signed-off-by: Chow Loong Jin <hyperair@debian.org>
Tested-by: <Magnus.Kessler@gmx.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
man: move ClickPad documentation into a single area

Having to read only one section is a tad easier than collecting the separate
options.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Ensure hw millis are monotonic (#48777)

The eventcomm backend takes the timestamp from the kernel, but the timer
uses the timer's "now". This timestamp may be later than the one from the
next event we read from the kernel, causing a negative dtime in get_delta()
and a cursor jump by (unsigned int)-1.

Ensure that the new event's timestamp is at least the last used one.

X.Org Bug 48777 <http://bugs.freedesktop.org/show_bug.cgi?id=48777>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Gavin Troy <gavtroy@gmail.com>
Print millis as unsigned int

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't release the button on TS_3 if TapAndDrag is disabled (#31854)

TS_3 is second tap down. Unconditionally set the button as down, later, in
HandleTapProcessing we have the required conditions to reset it to TS_START
and TBS_BUTTON_UP.

Meanwhile, TBS_BUTTON_DOWN stays down, so the second tap is counted and sent
as button event. This restores double-tapping if TapAndDrag is disabled.

X.Org Bug 31854 <http://bugs.freedesktop.org/show_bug.cgi?id=31854>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Update src/synproto.c license to the preferred MIT/X11 license

Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reset touch state on DeviceOff (#49161)

Don't leave touches lingering around during suspend.

Test case:
1) leave finger on touchpad
2) xinput set-prop "SynPS/2 Synaptics TouchPad" "Device Enabled" 0
3) lift fingers
4) xinput set-prop "SynPS/2 Synaptics TouchPad" "Device Enabled" 1

X.Org Bug 49161 <http://bugs.freedesktop.org/show_bug.cgi?id=49161>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Init num_touches to 0 on start

We implicitly rely on this already since we calloc the struct. Do it
expliclity on DeviceOn().

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
ClickPad is most definitely a bool option.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Don't unconditionally divide by scroll_dist_vert (#46617)

Regression introduced in cddab79c408db3b13905a2be72aff4f7bf1406f8.

If an event has a delta of less than scroll_dist_vert, the delta is
unconditionally divided by the distance, leaving some remainder close to 0
and never actually triggering the scroll amount.

Fix this by working with the increment, not the normalised values.

X.Org Bug 46617 <http://bugs.freedesktop.org/show_bug.cgi?id=46617>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Reset scroll delta when no finger is touching

Provides for a more consistent scrolling experience, otherwise delta
leftovers may trigger extra events even when the actual scrolling action
stays the same.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
synaptics 1.5.99.904

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Merge branch 'master' into led (v1.5.99.904)

* master:
  synaptics 1.5.99.904
  Reset scroll delta when no finger is touching
  Don't unconditionally divide by scroll_dist_vert (#46617)
  ClickPad is most definitely a bool option.
  Init num_touches to 0 on start
  Reset touch state on DeviceOff (#49161)
  Update src/synproto.c license to the preferred MIT/X11 license
  Don't release the button on TS_3 if TapAndDrag is disabled (#31854)
  Print millis as unsigned int
  Ensure hw millis are monotonic (#48777)
  man: move ClickPad documentation into a single area
  Fix coasting friction
  Stop coasting when two-finger scroll begins