…variable value.

    This corner case forces me to push my DLL060A:00 06CB:2734 trackpad really hard.

… and swipe4 gestures.

Till now gestures were delayed, but delay was before any button down event, so after first gesture you had to
"wait" for button down event, and button up was fired immediately after button down. It was like:
0 ms: gesture was made
... : delay for configured number of miliseconds
x ms: send button down and button up events (othen multiple times).
As a result actions bound to gestures via tools like xbindkeys were executed too late and othen more than once.
This comes from fact that xserver can "see" generated events only when 'read_input' callback returns.

To fix that I had to modify code to generate and "commit" buttown down events as fast as possible, and
use timer to be able to fire delayed button up events.
Actual flow looks like:
0 ms: gesture was made, button down
...: delay
x ms: one button up event
 and so on.

During development I merged code and data structures responsible for gestures configuration and execution.
Two finger scroll, swipes and four finger swipes are now executed by same function.
There are still some areas to merge, mostly in 'moving_update' and configuration code, but I didn't pushed it
further right now.

I also find and fixed bug with "ClickTime" property: it was set, but it wasn't used. Now taps will delay
button up for configured amount of time. Be aware to not set it to higher value than tap to drag wait time.
Otherwise delayed button up event may interrupt dragging.

…all four directions, but separate for gestures.

I guess most users would set all four variables to one value.
Also from this point delayed events will be fired early when user finish his gesture before even if it was scheduled for later.
So my earlier notes about too high tap click time and tap to drag are no longer valid: button up event will be send right after releasing any of touches.

…elopment of swipes.

The problem is swipe drag send motion events much slower than one finger motion.
Is it my fault, mtrack, mtdev or my touchpad?

…hing for source of huge delays and

found bugs in set_swipe_property.
This commit schold be removed/reverted.

…wn for xserver and user as "Trackpad {Scroll,Swipe,Swipe4} Settings".

Fixed bug in set_swipe_properties: now error code is handled correctly.
Changed few variable names to follow convention.

Conflicts:
	driver/mprops.c
	include/mprops.h
	src/mconfig.c

…le searching for source of huge delays and"

This reverts commit a4f206b.

Conflicts:
	driver/mprops.c
	src/mconfig.c

Swipe to drag is working, but I have to clean code, and implement "infinite timer" for hold == 0.

Updated readme and renamed property to "{Scroll,Swipe,Swipe4}Sensivity". Renamed variable to drag_sens.

… of Trackpad * Settings) will be treated

as infinite time. For 0 timer will be not set so button up event will be generated when user ends his gesture.

Additionally I cleanup code related to delays, removed delayed_delta member because it were duplicating delayed_time.

Some cleanups.

… so obvious at first sight.

…for fast swipes.