commit 9d7e3bf42052694c799da1e16ad7f60c913a492f
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Wed Feb 3 06:46:54 2021 -0800

    wacom 0.40.0
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit abffe85e3a873c63237b96e5d3d40172805f3822
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Tue Feb 2 14:49:29 2021 -0800

    Recognize pad devices which only have softkeys (e.g. Cintiq Pro 32)
    
    Devices like the Cintiq Pro 32 have pad devices that have no ExpressKeys.
    This prevents them from being recognized as a pad by the driver. When
    the device is connected, an `Invalid type 'pad' for this device`
    message would be logged.
    
    This has not been an issue in the past since there is nothing for the
    device to do without any ExpressKeys. Now that the driver is capable
    of forwarding the various softkeys as fixed-function keyboard events,
    however, it would be good to ensure that these kinds of devices are
    detected properly.
    
    Recognizing the device as a pad only requires us to expand on the list
    of tools that are known identifiers. Since we want softkey-only pads to
    be recognized, the two softkeys to the list. One or both of the keys
    should be present on devices like the Cintiq Pro 32, allowing the pad
    to be recognized as such.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit a93666436303b89d11eff7fd0e5de93d76a1e2d9
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Jan 17 15:20:45 2019 +1000

    Support the keycodes sent by the hardware buttons
    
    Forward the pad keys as keycodes KEY_PROG1-4. The evdev code has the right
    meaning, but we cannot route those keys (>255) so we just map them to
    KEY_PROG1-4 instead. This way we can in the future add a xkeyboard-config
    option to assign something to those keys.
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

commit 2f5f1096ee877a72f7d9585e56c98e07e8ed00b6
Author: Russell Haley <yumpusamongus@gmail.com>
Date:   Mon Aug 24 01:17:27 2020 -0500

    Stop pointer movement when panscrolling in relative mode
    
    Always stop pointer movement when a panscroll button is pressed in
    relative mode, instead of only when the pen is down. This keeps the
    pointer from "walking" when the user lifts the pen and scrolls
    repeatedly.
    
    Fixes: https://github.com/linuxwacom/xf86-input-wacom/issues/139
    Signed-off-by: Russell Haley <yumpusamongus@gmail.com>

commit 252bdda1ff71d1a167adfd0246464df536805746
Author: vintagepc <53943260+vintagepc@users.noreply.github.com>
Date:   Fri Jun 5 17:36:52 2020 -0400

    Better explanation of the "ToolSerials" option
    
    For https://github.com/linuxwacom/xf86-input-wacom/issues/128

commit 120dca3ae7dbcad382e148b2edde160e2020874a
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Thu Jan 21 13:25:10 2021 -0800

    Remove Travis integration
    
    Now that we've integrated with Github Actions, Travis is no longer
    necessary. Notably this does mean the loss of ppc64le testing, but
    it isn't a high priority target, and we will have lost that testing
    anyway once our free Travis credits run out...
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 065aec968f7a89dd74987b8eb50ab4615f0c4347
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Fri Jan 15 11:35:30 2021 -0800

    Add workflow for automated testing via Github Actions
    
    We've been using Travis for our automated tests, but that service is
    becoming more difficult to use (open source projects have to periodically
    request free credits to keep running). Github itself can be used as a
    replacement by using its "Actions" infrastructure to execute various
    defined workflows.
    
    This commit ports the Travis script into Github syntax. Most everything
    was translated without issue, but support for the ppc64le architecture
    is notably missing. This is not a critical target for us, however, so
    we ignore it for the time being.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit d56107e19a57bf3cf44e266a394da43397a8841a
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Fri Jan 15 10:24:10 2021 -0800

    gitignore: Add a few more entries
    
    Ignore the announce and sig files generated as part of the release process.
    Also ignore the version info generated as part of the compile process.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 2dc5769aaa91e8f61620a027af21b4e0b7ac1cc8
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Wed Dec 2 13:51:44 2020 -0800

    tools: update rules to handle bind/unbind events
    
    Summary: we expect add, change or remove but kernel 4.12 added bind and
    unbind. These events were previously discarded by udevd. Our rules should
    handle any event *but* remove, so update as suggested in the announce email
    linked below.
    
    For a longer explanation, see the system 247rc2 announcement
    https://lists.freedesktop.org/archives/systemd-devel/2020-November/045570.html
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit f9cc6a1dda10c1e8cdd1c68a7873c4d90665cb06
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Mon Nov 30 08:32:28 2020 -0800

    Increase size of event queue to 128
    
    The size of the event queue defines how many kernel events we can keep
    track of before seeing a SYN_REPORT. If we are ever asked to handle
    more than this limit, data is dropped with unpredictable consequences.
    Our previous queue size of 32 was usually sufficient but could still
    be bumped into in edge-cases. Updating 8 or more touch contacts at the
    same time could sometimes cause the queue to run out of space, for
    example.
    
    This commit bumps the queue size up to 128. This should be more than
    enough for all current devices (some of which can track up to 16 contacts).
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit a7f88f9c0194c8ecaffb81b073f3620b8b90b014
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Mon Nov 30 08:32:11 2020 -0800

    Remove duplicate MAX_USB_EVENTS definition
    
    A definition of this macro already exists in wcmUSB.c and is not used
    in any other file. There's no need for this duplicate to exist.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 9b7d679ebe1f12eb61814dcd9aba6f7cbdedbb57
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Oct 19 16:25:05 2020 +1000

    travis CI: order ppc64le after amd64
    
    https://docs.travis-ci.com/user/multi-cpu-architectures/ says that "explicitly
    included builds inherit the first value in an array" and the example there
    matches our configuration.
    
    Moving ppc64le to after amd64 means the coverity job we have is now (again)
    run on amd64 only, fixing the current test case failures - Coverity doesn't
    support ppc64le.
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

commit 9bf6954aaee05ebc32d86ca8297d8bcbe927c46f
Author: kishorkunal-raj <mr.kishorkunal@gmail.com>
Date:   Mon Sep 21 07:40:38 2020 +0000

    Adding ppc64le architecture to support on travis-ci

commit a4372a2e6083312defc9eef2806ebea98f02fa1a
Merge: 095ba9c 304ee7e
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Mon Aug 3 08:26:00 2020 -0700

    Merge pull request #137 from Pinglinux/for-cintiq-16-2
    
    Support new Cintiqs for older kernels
    
    Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 304ee7eefc355176334518449a363e65afb341b2
Author: Ping Cheng <ping.cheng@wacom.com>
Date:   Wed Jul 29 13:29:47 2020 -0700

    Support new Cintiqs for older kernels
    
    Kernels older than 2.6.38 do not report INPUT_PROP_DIRECT
    
    Signed-off-by: Ping Cheng <ping.cheng@wacom.com>

commit 095ba9c48e8cf8a96970e211ed734ba5883a0025
Author: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
Date:   Tue Jan 7 11:24:15 2020 -0800

    Add new "Wacom One Pen Display 13" PID
    
    Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>

commit 0fb1699b48a36a564ce3b928d90be27f896c220a
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Fri Dec 20 10:42:31 2019 -0800

    wacom 0.39.0
    
    Signed-off-by: Jason Gerecke <killertofu@gmail.com>

commit a3b03e8638c037132fdf0927c7e488ec80967a5c
Merge: 3b33831 a2f52bd
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Mon Dec 16 13:01:39 2019 -0800

    Merge pull request #96 from jigpu/add-new-msp-pid
    
    Recognize new MobileStudio Pro PID
    
    Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>

commit a2f52bd6b338031331fefe074d22b7ed19057341
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Fri Dec 6 11:26:51 2019 -0800

    Recognize new MobileStudio Pro PID
    
    A new PID is in use for repaired MobileStudio Pro devices. Add it to the
    various device properties lists.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 3b338312eb275f2d9a602805931fa47d863a0209
Merge: b40122d 5113d18
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Mon Nov 4 09:14:40 2019 -0800

    Merge pull request #92 from jigpu/fix-74
    
    Ignore ABS_MISC as a source of device type information for AES pens

commit 5113d18300bfae2dbffc78c67aef0760d612d995
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Mon Sep 23 14:29:09 2019 -0700

    Ignore ABS_MISC as a source of device type information for AES pens
    
    AES sensors use protocol 5 since they send ABS_MISC events which contain
    information about the tool type in use. The tool type information sent
    by AES sensors does not match that used by EMR sensors, however. In
    particular, it is not possible to extract stylus/eraser/puck information
    from the ID.
    
    The driver would normally never try to extract this information, but the
    problem was highlighed when a bug in the kernel would cause the device ID
    to be reported twice: once in a packet alongside a BTN_TOOL_* event (fine)
    and a second time in a packet without such an event (causing the driver
    to try to figure it out from the ID instead).
    
    This commit adds detection for AES pen IDs and does not try to extract
    such information if an AES pen is in use. We assume that any protocol 5
    device which predates the use of Intuos5-era technology uses the legacy
    IDs.
    
    Ref: https://github.com/linuxwacom/input-wacom/issues/134
    Fixes: https://github.com/linuxwacom/xf86-input-wacom/issues/74
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit b40122dd49ca2cdd2d2608f30e5340d5c963187d
Merge: 17028f6 2a7af30
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Wed Oct 23 13:50:18 2019 -0700

    Merge pull request #90 from jigpu/fix-86
    
    tools: Fix potential buffer overflow when reading from serial tablet
    
    Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>

commit 2a7af30793f9aa6e36acdc7c8b908d0965585437
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Thu Oct 10 12:13:39 2019 -0700

    tools: Fix potential buffer overflow when reading from serial tablet
    
    The read_data() function has a "min_len" number of bytes to read
    to ensure that a complete data structure is read, regardless of garbage
    that may be on the line. When garbage is present, however, it can
    potentially overflow the buffer.
    
    The function already has code to memmove the good data over garbage and
    perform re-reads until "min_len" bytes of good data are available. All
    we need to do to avoid the buffer overflow is ensure that the maximum
    number of bytes we read() in one call is no more than the number of
    bytes free at the end of the buffer.
    
    Ref: https://github.com/linuxwacom/xf86-input-wacom/issues/86
    Fixes: 3546d8ab1b ("tools: add isdv4-serial-debugger test program")
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 17028f68f5ca41cf6c77e4166e48006e6c3fff45
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Mon Oct 14 10:40:45 2019 -0700

    wacom 0.38.0
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 6e42a0806f61b112deee4e4fa30daf23a435e40c
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Wed Oct 9 14:25:21 2019 -0700

    wacom 0.37.99.1
    
    Signed-off-by: Jason Gerecke <killertofu@gmail.com>

commit 76878df9a7bbcead2375a19fd1683f830e6941bb
Merge: 3a4b961 af2fafd
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Wed Oct 9 14:04:22 2019 -0700

    Merge pull request #84 from jigpu/gesture-mods
    
    Gesture mode default change
    
    Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>

commit af2fafdff96ba4f087fcbe4ce4ddc57916614e84
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Wed Sep 4 10:27:08 2019 -0700

    Handle multitouch mode up at the very start wcmGestureFilter
    
    Moving the code which handles multitouch mode to the start of the function
    both makes the code more obvious and ensures that we don't accidentally
    recognize an unwanted gesture. Doing so much partial-processing before
    eventually hitting a "goto ret" and handling multitouch mode was tricky
    to understand and hard to verify.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 009f7424a21cd56404c9827d69e6920551bf43c8
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Wed Sep 4 10:03:13 2019 -0700

    Perform a few cleanups in wcmTouchFilter.c
    
    Removes the #ifdef compile guards around the code that checks if gestures
    are disabled prior to doing multitouch processing. They aren't strictly
    necessary, and actually prevent "gesture off" from having an effect on
    older X servers.
    
    Also removes a vestigial check in wcmFingerMultitouch. The original
    version of the function would only be called once two or more fingers
    were down. This gave wcmSingleFingerPress a chance to send a left-click
    event when just a single finger came in contact with the touchscreen.
    Later it was realized that the MT protocol requires us to send even
    *single* touch events for touchscreens through its API, so the code was
    changed to *always* call wcmFingerMultitouch when a touchscreen was in
    use. This had the side-effect of never calling wcmSingleFingerPress,
    rendering this check useless.
    
    Also removes some unnecessary checks from the zoom/scroll processing
    that are either already handled by pre-conditions above or have no
    real effect.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 31a5405f7d9405bc514585709161287b0c67386e
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Mon Sep 9 15:32:17 2019 -0700

    Change default gesture mode: touchpad=on, touchscreen=off
    
    A large number of users run the GNOME desktop which has its own gesture
    engine that performs actions on touchscreens. These gestures are much
    better than the ones we provide, so lets disable our engine by default
    for touchscreens. Note that GNOME doesn't do anything with touchpad
    gestures, so we leave them enabled by default.
    
    Note that this change will effectively cause a feature regression for
    users of other environments that do *not* have their own gesture
    engines (Cinnamon, KDE, MATE, XFCE, etc.). Users will want to add an
    xorg.conf.d snippet with `Option "Gesture" "on"` to bring back the
    functionality.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 3a4b96139e27a593c869fe28999211d6c90142eb
Merge: ef94319 3eb70ae
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Thu Sep 12 15:07:01 2019 -0700

    Merge pull request #78 from Pinglinux/master
    
    Support new MobileStudio Pro for older kernels
    
    Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 3eb70aeb87a2aed091cf3bd80e6236aa9c1fdbaf
Author: Ping Cheng <ping.cheng@wacom.com>
Date:   Tue Sep 10 21:40:58 2019 -0400

    Support new MobileStudio Pro for older kernels
    
    Support new MobileStudio Pro 13 and 16
    
    Signed-off-by: Ping Cheng <ping.cheng@wacom.com>

commit ef943197cc912f782412dcbe02aac92a8fb4d61f
Merge: 0ac49a2 a38074d
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Mon Sep 9 14:43:45 2019 -0700

    Merge pull request #77 from jigpu/issue-43
    
    Improve gesture recognition and usability
    
    Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>

commit a38074dcfb2350c0253ae4ac3c3745c4977596e5
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Wed Jul 24 13:48:08 2019 -0700

    Trigger scroll and zoom gestures immediately after they are detected
    
    The amount you have to move your fingers to start a gesture is quite a
    larger than the amount you have to move them to continue to gesture.
    This makes the smooth use of gestures difficult since it can be a little
    unpredictable exactly when they finally kick in. By triggering the zoom
    and scroll gestures at the same distance as it takes to continue them,
    the gestures feel much more smooth to execute.
    
    This commit removes the various delays that prevent gestures from being
    executed the moment the configured scroll or zoom distance is achieved.
    
    Ref: https://github.com/linuxwacom/xf86-input-wacom/issues/43
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 3cf2348aa5b3cb169a0b9d5ce06a243dcd009e0c
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Mon Jun 25 14:54:41 2018 -0700

    Revert "Reset wcmGestureState to current device state upon gesture start"
    
    This reverts commit 8f85692a19bd34dae77071a296a14c01a491cf4a.
    
    In the next commit we will be starting gestures immediately on detection,
    eliminating the need for this commit. (Indeed, its existance actually
    is an additional delay of 1 event distance to immediate execution)
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 73c0fdb41eeea00667029d5eea1129c0ad14e17e
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Wed Jul 24 13:26:34 2019 -0700

    Do not start scroll gesture if fingers are moving opposite directions
    
    The driver sometimes has difficulty distinguishing scroll and zoom
    gestures. This is caused by a combination of the zoom spread distance
    being larger than the scroll distance and the "pointsInLine" checks being
    blind to fingers moving in opposite directions. Zoom gestures that have
    fingers moving in opposite directions along the same axis are especially
    likely to be misinterpreted as a scroll.
    
    To improve recognition accuracy, this commit adds a function that verifies
    the two fingers are actually moving in the same direction. As long as the
    motion vectors for the two fingers are more than 90 degrees apart, scrolling
    will be inhibited. The allowed difference could be significantly reduced if
    necessary, but this seems to do the trick for me.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 8cc538503cdadcf6e4801c53a6ad1badc8c7e2d4
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Fri Jun 15 11:34:12 2018 -0700

    Minor cleanups for wcmFingerScroll and wcmFingerZoom
    
    Make some especially-long lines a little easier to read.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 813391f78e3d0a10292b234fc103e60f42362c70
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Fri Jun 15 11:43:44 2018 -0700

    Use wcmScrollDistance as scroll threshold; recognize scrolling more consistently
    
    The wcmFingerScroll function runs a series of checks when trying to
    recognize a scroll gesture. The first check is that the fingers have
    not spread apart (or come closer together) by more than a specified
    distance (wcmMaxScrollFingerSpread). The next check is that both
    fingers are moving in the same direction. This second check is performed
    by 'pointsInLine', which returns 'TRUE' if the contact has moved in the
    expected direction by some minimum distance. This minimum distance was also
    set to wcmMaxScrollFingerSpread, despite it not really being a measure of
    finger spreading.
    
    This commit changes the minimum distance to be wcmScrollDistance: the
    distance at which a scroll event would normally be emitted. This will
    cause scrolling recognition to feel consisitent with the rest of the
    scrolling experience, eliminating the lag between starting a scroll
    gesture and the driver recognizing it. As long as you move your fingers
    one scroll distance, scrolling will begin.
    
    Users who have a very small scroll distance may find this change makes
    it harder to trigger a pinch zoom since the fingers must move apart or
    together by at least wcmMaxScrollFingerSpread before moving up/down/left/right
    by the scroll distance.
    
    Ref: https://github.com/linuxwacom/xf86-input-wacom/issues/43
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 1f52ad54c1ae66e25a28c2ca1178921118f9d9c1
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Mon Jun 25 10:41:56 2018 -0700

    Overhaul calculation of default scroll, zoom, and spread distances
    
    The default values for zoom, scroll, and spread distances were originally
    fine-tuned for use with a 3rd-gen Bamboo small tablet (e.g. CTH-470). The
    code tries to scale these values to work with other sensors, but there are
    a couple of problems with the actual logic:
    
    1. The scaling is done based on the logical size of the tablet. This is
    problematic for some generations of tablet (including the 3rd-gen Bamboos)
    which use sensors with an identical logical size despite different physical
    size. This means that larger tablets in these generations require larger
    gestures to accomplish the same task.
    
    2. The scale factor for the scroll distance is calculated with respect to
    the X axis, even though it is far more common to scroll vertically than
    horizontally. For devices with a different resolution in the X and Y axes,
    this means that calculated default won't be consistent with devices that
    have the same resolution in both the X and Y axes.
    
    This patch makes several modifications to simultaneously address all
    three of the issues. We replace the logical Bamboo-referenced numbers
    with equivalent millimeters, calculate the logical distances based on
    the kernel-reported resolution (using the resolution of the Bamboo if
    not available), and specifically scale scroll distances with respect
    to the Y axis.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 65b7c37f0fac5cdd03ff7f977124148d0bdf4be8
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Mon Jun 18 07:09:03 2018 -0700

    Prevent spurious right-clicks at the end of very short scroll and zoom gestures
    
    If you perform a two-finger scroll/zoom gesture that takes less than
    wcmTapTime milliseconds to complete and has the second touch going up
    before the first, the wcmFingerTapToClick function may trigger a right-
    click event as you complete the scroll/zoom. The reason for this is
    that we call wcmFingerTapToClick for any non-scroll/zoom gesture state.
    This isn't technically correct: we should really only be calling the
    function when in the LAG state (i.e., while waiting for a two-finger
    gesture to occur).
    
    The logic which moves single-finger non-DRAG states into LAG or NONE
    modes can conflict with simply checking for the LAG state before calling
    wcmFingerTapToClick because very short drags can also be less than
    WACOM_GESTURE_LAG_TIME, which will move the ZOOM and SCROLL states to
    (single-finger) LAG mode and trigger the right-click gesture anyway.
    To ensure this doesn't happen, we add a check for single-finger SCROLL
    and ZOOM states just before this block and have it move the mode to
    CANCEL which will only be reset once both fingers have gone up.
    
    Fixes: 68daad26c11d ("improve initial 2 finger behavior")
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 8188891c120af14f3cea28ad72ed0cf61eaa2988
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Fri Jun 15 14:28:23 2018 -0700

    Do not wait wcmTapTime to enter scroll or zoom mode
    
    Commit 3005fc0 reduced the amount of time that we wait before entering
    scroll and zoom mode, mentioning that the only reason we want to wait
    at all is to process time-based two-finger gestures. The commit hints
    at a "2 finger tap" being the only gesture which this would apply to,
    but there are no signs of that gesture in the driver anymore. There is
    the right-click gesture which requires that the second finger be tapped
    for less than wcmTapTime, but removing the wcmTapTime limit on entering
    scroll and zoom modes does not affect that gesture (unless your right-
    click gesture was so sloppy that your fingers moved enough to be
    considered a scroll or zoom gesture).
    
    Ref: https://github.com/linuxwacom/xf86-input-wacom/issues/43
    Ref: 3005fc0 ("reduce 2-finger scroll holdoff time")
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 0ac49a26d25279b7777239066aff8e1f5f23bd4b
Merge: 299e830 bde3339
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Tue Sep 3 13:29:39 2019 -0700

    Merge pull request #73 from jigpu/fix-54
    
    Allow stylus devices to have "CursorProximity" effect in relative mode
    
    Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
    Reviewed-by: Ping Cheng <ping.cheng@wacom.com>

commit bde3339eb056d8ac237b9caacdef20dcf38d0d9f
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Wed Jul 24 10:17:17 2019 -0700

    Use a proxout height of 30 for all stylus devices
    
    Styli and pucks likely have different proxout height requirements due
    to differences in how the tools are held/used. For now, lets try setting
    a height of 30. This should be close to the height previously present for
    consumer devices (before the kernel started honoring prox/range) and
    should hopefully be reasonable for professional devices too.
    
    Ref: https://github.com/linuxwacom/input-wacom/issues/54
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 4890de5f9a29e739591bed288528661f7c23f86d
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Thu Aug 1 10:49:41 2019 -0700

    Allow CursorProximity to take effect even if distance == 0 on tablet surface
    
    The CursorProximity feature allows the relative-mode puck to be lifted a
    smaller distance from the tablet surface than the full hardware prox
    distance. This makes using the puck in relative mode much easier. In order
    to simplify the code, 4893844f3f changed how the surface distance would
    be determined. Instead of tracking the minimum (or maximum) distance
    reported, the driver would use the value reported the moment a click
    occurred. This works relatively well, but does require the user to make
    at least one click before the CursorProximity feature takes effect.
    
    Because the "uninitialized" value of `common->wcmMaxCursorDist` is zero,
    this can prevent the CursorProsximity feature from taking effect if the
    tablet itself reports a distance of 0 at the tablet surface. To fix this
    we can just let the "uninitialized" value be -1 since such a distance
    is not valid.
    
    Ref: https://github.com/linuxwacom/xf86-input-wacom/issues/72
    Fixes: 4893844f3f ("Modify wcmMaxCursorDist calculation to support non-inverted protocol 4")
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit a13f2bfe177b9eb0f747d1eb9044840f48d762cd
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Wed Jun 19 09:25:30 2019 -0700

    Allow use of proxout feature for any relative tablet tool (stylus, eraser, cursor)
    
    The proxout feature makes it easier to use tools in relative mode by not
    requiring the user to completely remove the tool from hardware prox before
    repositioning. Traditionally only the cursor tool is used in relative
    mode, but there are also times that stylus/eraser might also be. This
    patch allows any relative tablet tool to make use of the feature.
    
    Ref: https://github.com/linuxwacom/input-wacom/issues/54
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 2cf46016810056d3fd08c6b7dec3b33089f64672
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Wed Jun 19 09:05:46 2019 -0700

    Change wcmCursorProxoutDist from a common to a private property
    
    Refactors wcmCursorProxoutDist and related variables so that the information
    is tracked on a per-tool basis rather than being considered a common property
    of the tablet. This is in preparation for a follow-up patch which will expose
    the proxout feature to tools other than the cursor/puck.
    
    Ref: https://github.com/linuxwacom/input-wacom/issues/54
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 299e830bb7fcc4d73bbad12244de90d0c4bdd9d3
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Jul 19 14:47:54 2019 +1000

    travis CI: rework and simplify
    
    Does the same work, but it's a bit easier to understand now. The 'compiler'
    directive creates two jobs, gcc and clang. Those jobs use the global
    instrucitons.
    
    In addition we have the 'jobs' directive which adds the coverity job, broken
    up over multiple lines now to make live easier on our eyes.
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 0ce40261fb6acda37f68a4fadb39c46565e94a8e
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Jan 17 13:44:37 2019 +1000

    Remove misplaced comment
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

commit daafdda6e90d9c36ad8f56be1f03d0b402595f30
Merge: 4e06527 6a95129
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Mon Jul 29 11:51:45 2019 -0700

    Merge pull request #67 from skomra/master
    
    Remove and replace references to Sourceforge

commit 4e065272eaed6ab27fe17627712fdb7ecd697fa5
Merge: 2248962 030d272
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Tue Jul 16 10:29:05 2019 -0700

    Merge pull request #66 from ShapeShifter499/master
    
    Add support for Surface Go and Nuvision Solo 10 Draw

commit 6a95129703b469b51d600f464208abe852e745e2
Author: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
Date:   Tue Jul 16 10:21:31 2019 -0700

    Remove and replace references to Sourceforge
    
    The project has moved to Github.
    
    Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>

commit 030d272d5d605f9605ed44cdde4856737415a972
Author: ShapeShifter499 <Gero3977@gmail.com>
Date:   Mon Jul 15 01:36:27 2019 -0700

    Add support for Surface Go and Nuvision Solo 10 Draw
    
    For Surface Go and Nuvision Solo 10 Draw
    
    Signed-off-by: Lance Geroso  <gero3977@gmail.com>

commit 2248962cf15334c6f61a82ab4efedfcd2e85a741
Merge: b164be0 5089f0c
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Thu Jun 20 16:06:35 2019 -0700

    Merge pull request #63 from jigpu/fix-59
    
    Fix panscroll when using non-default tablet area

commit 5089f0c886bd42511edc99080af38c9dcb205171
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Tue Jun 18 08:35:34 2019 -0700

    Fix panscroll when using non-default tablet area
    
    Attempting to perform a panscroll operation on a tablet that has a non-
    default area set can cause scrolling to occur even when the pen isn't
    moved. The direction of scrolling may change depending on the position
    of the active area (e.g. scrolling down when the area is on the top;
    scrolling up when the area is on the bottom).
    
    The cause is a result of the current and previous DeviceState structures
    (`ds` and `priv->oldState`) containing different information about the
    pen location. While the current state contains the untransformed device
    coordinates, when `wcmUpdateOldState()` is called, the XY information is
    replaced with the transformed version.
    
    To fix this issue, we modify the wcmPanscroll function to take X and Y
    as explicit parameters that are obtained from the valuators. These are
    transformed values and so will be compatible with changes to the area.
    Because the valuator data may have been transformed to a delta within
    wcmSendNonPadEvents we also need to add a check if the device is in
    relative mode and then act appropriately.
    
    Ref: https://github.com/linuxwacom/xf86-input-wacom/issues/59
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Reviewed-by: Ping Cheng <ping.cheng@wacom.com>

commit b164be0e372ac5602b2c5b02e90b2cfb0268160c
Author: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
Date:   Mon Jun 17 14:18:09 2019 -0700

    wacom 0.37.0
    
    Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>

commit a3e880ec34e7e9ef01098a899a4b1eb113b82b51
Merge: 5fc2d91 3657396
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Wed Jun 12 13:11:10 2019 -0700

    Merge pull request #62 from jigpu/issue-52
    
    Fix issues with Microsoft Surface Go tablet

commit 5fc2d91ead58c8a5ae38f5cfe92de1d214aba5d7
Merge: d0a68b8 dbb07c5
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Wed May 29 12:06:04 2019 -0700

    Merge pull request #58 from skomra/master
    
    Add feature flags for several missing tablets

commit 365739656df5361533a57494db327ecbc7cb4b8a
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Fri May 24 14:51:32 2019 -0700

    USB: Apply WCM_PROTOCOL_GENERIC to non-Wacom hardware
    
    It seems that some non-Wacom tablets have an ABS_MISC axis that makes
    our driver try to apply special Wacom-only axis behaviors. This commit
    makes the driver use WCM_PROTOCOL_GENERIC for any device that does not
    have Wacom's VID.
    
    Ref: https://github.com/linuxwacom/xf86-input-wacom/issues/52
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 3b30bb3dcd64d9467e5b5e2cbe014c11bd347317
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Fri May 24 14:38:12 2019 -0700

    USB: Don't use ABS_MISC for tool ID information with a generic tablet
    
    Generic devices don't store tool ID information in ABS_MISC, so we should
    be careful to not accidentally interpret other miscellaneous data as such.
    
    Ref: https://github.com/linuxwacom/xf86-input-wacom/issues/52

commit 33cdf63a0089bdd1e66e350cc621b80415a7c8ba
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Fri May 24 14:13:08 2019 -0700

    USB: Split handling of generic and protocol 5 ABS events
    
    Many Wacom devices use a non-standard meaning for several axes and
    we should be careful not to apply those meaning when receiving events
    from a generic device. Incorrectly using the non-standard meanings
    can cause the driver or userspace to become confused.
    
    Ref: https://github.com/linuxwacom/xf86-input-wacom/issues/52
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit dbb07c56366a7d95c0392d8207baeff8de20063d
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Wed May 1 09:04:12 2019 -0700

    Add feature flags for several missing tablets
    
    Feature flags are used by the driver to determine if a particular device
    needs special treatment. The devices usually work "okay" without these
    flags set, but missing flags can result in some features not working
    or not working as expected. For instance, the touch ring on the Bluetooth
    interface of the 2nd-gen Intuos Pro does not work at the moment because
    the WCM_RING feature is missing. It also gains the WCM_ROTATION flag.
    All other devices added gain the WCM_LCD flag, as well as the WCM_ROTATION
    flag if the device supports pen rotation.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>

commit d0a68b873e015eb967718e60dbc3967f38a5e169
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Apr 12 13:36:00 2019 +1000

    release.sh: pass the module name to the github release function
    
    We don't want to post libwacom releases to xf86-input-wacom
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

commit b3604240a920e780a130ea84da67fc7483213937
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Apr 12 13:31:57 2019 +1000

    release.sh: don't release to github in dry-run mode
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

commit 0f4e77ff632d4c5dc37e90395d6a6c44c843e06c
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Nov 5 10:44:01 2018 +1000

    release.sh: drop sourceforge release bits
    
    We're well and truly on github now
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

commit 2062126997bfe2c014533873d73a95198b335305
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Dec 10 11:03:22 2018 +1000

    xsetwacom: error if we're running this under Wayland
    
    xsetwacom cannot work under Wayland, even with XWayland because there is no
    xf86-input-wacom driver. So let's not continue normally and not find any
    devices because that'll be confusing to the user when the tablet is clearly
    working.
    
    Print an error and exit code of 1.
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

commit 84400df38f0f9abe664de26a8d3747b10f3a05e5
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Oct 24 10:35:17 2018 +1000

    Remember the event types we receive and skip events with no data
    
    On RHEL7.x kernels we get event frames with merely MSC_SERIAL -1 for some
    devices on proximity in. This is caused by the accelerometer data that is
    otherwise suppressed by those kernels.
    
    E: 123.456 0000 0000 0000       # ------------ SYN_REPORT (0) ----------
    E: 123.456 0004 0000 -001       # EV_MSC / MSC_SERIAL           -1
    
    For a MSC_SERIAL -1 we default to the PAD_ID (0x10), despite the events
    happening on the Pen device node. This triggers an error message during EV_SYN
    processing:
    
       (EE) usbDispatchEvents: Device Type mismatch - 16 -> 0. This is a BUG.
    
    Once we receive the BTN_TOOL_PEN when the actual pen comes into proximity, the
    error message goes away because our tool type matches with what we expect.
    
    Fix this issue by remembering which event types we received in the current
    frame. If all we got was EV_MSC, skip the event dispatch - we don't have any
    data to process anyway.
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Reviewed-by: Ping Cheng <ping.cheng@wacom.com>

commit 8a6f201fde45b6aef9785bdfbfd0d908ff1c4071
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Oct 24 10:15:58 2018 +1000

    Split EV_MSC handling out of the EV_SYN handling
    
    The only thing these two had in common was the reset of the event count on
    failure. Might as well split them up to make the code more readable.
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Reviewed-by: Ping Cheng <ping.cheng@wacom.com>

commit cafb587a4eb89d906317dbe347198b523e494c76
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Oct 24 10:21:40 2018 +1000

    Reformat a debugging message
    
    No functional changes but makes grepping for it a lot easier
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Reviewed-by: Ping Cheng <ping.cheng@wacom.com>

commit 6e2728780056614e4b2f37abde4f60f072edc95a
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Oct 24 10:10:46 2018 +1000

    Correct two comments
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Reviewed-by: Ping Cheng <ping.cheng@wacom.com>

commit 71b35110478b8fce410c017e24072b6ab588d551
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Fri Sep 28 15:52:29 2018 -0700

    Support DTU-1141B on older kernels
    
    Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

commit c091c9e295db9c271de60c87a1a9ce921d638159
Author: James Pearson <james-p@moving-picture.com>
Date:   Thu Aug 9 09:11:16 2018 +1000

    Running 'xsetwacom get $id Serial' gives:
    
      Unknown parameter name 'Serial'.
    
    'Serial' should be in the deprecated parameter list - also 'GetTabletID'
    is defined twice in the same list
    
    Signed-off-by: James Pearson <james-p@moving-picture.com>
    Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

commit 192d67275c6621ec7debef3c6453dd2030b7cac8
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Thu Jun 21 14:08:40 2018 -0700

    travis: Hotfix Coverity's Travis integration patch
    
    Coverity has been triggering build errors for quite a while now, simply
[--snip--]
