Use serial number instead of channel number to identify contacts

Code that deals with touch points shouldn't care which channel an
event is occuring in; it should be more concerned with the finger
that caused it. At the moment these are the same things (first
finger is always in channel zero), but this will soon change.

Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Dynamically find touch channels, instead of hard-coding

Right now the driver assumes that the first touch will always
be in channel 0, and the second touch (if present) is in
channel 1. This patch adds a new function to scan the channel
list for appropriate contacts, and uses it instead of the
hard-coded index accesses.

Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Make usbInitToolType more generic, and always use

Tweaks the usbInitToolType function to be always useful. This is
needed so that we can use it to get the tool type for all event
frames, allowing us to properly fill in the tool type for devices
that we otherwise don't figure out until later on (which causes
problems with the proper operation of usbChooseChannel).

Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Simplify usbChooseChannel logic

Instead of having different per-protocol cases, just obtain serial
numbers equivelent to those you'd get from Protocol 5 and then
use that serial to find a channel dynamically.

Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Have usbChooseChannel take explicit device type and serial args

Instead of divining this information from the stored private data,
take them as arguments. This gives us more flexibility in finding
channels for sub-tools (e.g. individual fingers).

Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Dynamically choose channel for ABS_MT data

Now that the touch code doesn't look in statically-defined
channels and usbChooseChannel is capable of locating channel
numbers for arbitrary tool type/serial combinations, we can
use the latter to track an aribrary number of touches without
fear of stepping on the toes of another channel.

Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Use new multitouch protocol in XI2 if possible

Adds a new MULTITOUCH gesture mode that will redirect all in-contact
touches through the new multitouch code available in XI2.2 (ABI >= 16).

MULTITOUCH mode will only be entered when in-driver gestures have been
disabled and at least two fingers are present. The driver will remain
in this mode until *all* fingers have left the tablet.

For the moment, all touches are sent as XIDependentTouch. Direct touch
devices such as tablet PCs and Cintiqs are not an exception. This may
be changed in the future once frameworks are better equipped to handle
direct input touches.

Signed-off-by: Jason Gerecke <killertofu@gmail.com>
RFC: Move check for enabled gestures to the functions that execute them

At the moment, disabling gestures disables *all* gestures. That includes
the core "tap to click" gesture (and slightly-less-core "tap and hold to
drag"). This patch allows these two gestures to not be considered such
by moving wcmGesture check into the functions that execute the gesture.
All two-finger functions (right click, scroll, and zoom) are disabled by
wcmGesture, but all single-finger functions remain operational.

I'm not sure if we want this patch or not...