Use serial number instead of channel number to identify contacts

The gesture filter doesn't really care which channel an event is
occuring in; it cares which finger was responsible for it. At the moment
these are one and the same (first finger is always in channel zero), but
will not necessarily always be true.
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).
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>
WIP: Use new multitouch protocol in XI2 if possible

Adds a new wcmSendTouchEvents function that all the raw touches coming
from a tablet can be routed to. This codepath is only available for
servers with ABI >= 16, and when in-driver gestures have been disabled.

Note that when this codepath is in use, single-touch events are *not*
generated. This means that single-finger navigation and clicking does
not work.

TODO: Differentate between direct and dependent touch devices to
get X working in the right mode.

TODO: Figure out what's up with xf86InitTouchValuatorAxisStruct. Is that
broken documentation, part of a newer ABI, or what?
Add a new GESTURE_MULTITOUCH_MODE to allow single-finger navigation

The addition of this new gesture mode allows wcmTouchNeedSendEvents to
properly report when the cursor needs to move. This mode is entered
if gestures have been disabled, no gesture is in progress, and a second
contact has entered proximity. The driver will remain in this mode so
long as at least one contact remains in proxmity.
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...