wacom 0.24.0

Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Remove unused code

usbFindDeviceType() is only called once. From where it
is called, it is only called if event->value != 0 and
with ds->device_id = event->value.
Thus the test !ds->device_id will always fail.

Signed-off-by: Egbert Eich <eich@suse.com>
Reviewed-by: Jason Gerecke <killertofu@gmail.com>
Zero is not a valid device ID, don't derive a type from it

A protocol 5 tool will send an ABS event code=ABS_MISC with
value 0. 0 is however not a valid device ID. Don't try to
derive a type from it.

Signed-off-by: Egbert Eich <eich@suse.com>
Reviewed-by: Jason Gerecke <killertofu@gmail.com>
Fix initial device type detection

usbInitToolType() tries to find the device type of a tool.
Unlike usbFindDeviceType() it doesn't take into account the device_id
which may exist in the event stream.
As a result the device type may be taken from the last known type.
This is generally a bad idea if the type has changed.
This will happen for example when pressing a key on the Cintiq 21UX menu
strips after removing a pen from the tablet.

Signed-off-by: Egbert Eich <eich@suse.com>
Reviewed-by: Jason Gerecke <killertofu@gmail.com>
Store the last used channel rather than blindly taking channel 0

When an event stream from a device doesn't contain information
on the device type we look at the last used channel and copy
over the device type.
This is acceptable as such a situation only occurs while in
proximity i.e. when the previous command package came from
the same device.
So far the device type form the state in channel 0 was taken.
This was wrong however for PAD devices for instance.

Signed-off-by: Egbert Eich <eich@suse.com>
Reviewed-by: Jason Gerecke <killertofu@gmail.com>
Remove duplicate tool type detection

Tool type detection is done in two places: early in usbDispatchEvents()
by calling usbInitToolType() and later on in the same function when the
events are parsed.
usbInitToolType() is used to set (wcmUSBData*)->wcmDeviceType, the
detection that happens later when the events are parsed sets
(WacomDeviceState).device_type. These variables are matched against each
to find the right channel for a device.
If the algorithms used for both set of tool type detection diverge
undesirable effects may happen. Therefore it is advisable to determine the
tool type only once ie. in usbInitToolType() and copy the result to
(WacomDeviceState).device_type if this value is unset.

* Bring the algorithm in usbInitToolType() in sync with the reset:

  Add missing key codes to deviceTypeFromEvent()

  - Add BTN_TOOL_DOUBLETAP and BTN_TOOL_TRIPLETAP, return
    TOUCH_ID for them.

  - Return TOUCH_ID on BTN_TOUCH when protocol level is
    WCM_PROTOCOL_GENERIC and tool is a 1 finger USB touch.

* Delete any duplicate tool type setting

* Add a test for debugging if the device type has changed while in proximity.

Signed-off-by: Egbert Eich <eich@suse.com>
Reviewed-by: Jason Gerecke <killertofu@gmail.com>
Attempt to derive the tool type from a known button/key event

This is the last bit of clean up and consolidation in tool type detection:
usbParseAbsEvent() sets the tool type if it recognized a button or key
event and the tool type has not been set before.
Before we get to usbParseAbsEvent() channel mapping must have failed most
certainly so we must have gotten a new channel for each button or key
sequence.
Since this seems to be a last resort attempt to determine the tool type
we only do this when all other methods have failed before. The newly
introduced function deriveDeviceTypeFromButtonEvent() mimics the behavior
of usbParseAbsEvent().

Signed-off-by: Egbert Eich <eich@suse.com>
Reviewed-by: Jason Gerecke <killertofu@gmail.com>