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: 3b338312eb27 a2f52bd6b338
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: b40122dd49ca 5113d18300bf
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: 17028f68f5ca 2a7af30793f9
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: 3a4b96139e27 af2fafdff96b
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: ef943197cc91 3eb70aeb87a2
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: 0ac49a26d252 a38074dcfb23
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: 299e830bb7fc bde3339eb056
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: 4e065272eaed 6a95129703b4
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: 2248962cf153 030d272d5d60
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: b164be0e372a 5089f0c886bd
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: 5fc2d91ead58 365739656df5
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: d0a68b873e01 dbb07c56366a
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
    because their server returns a different success code after uploading
    than their script demands. We've notified them about this bug, but
    nothing seems to be happening. Lets just patch the broken code and move
    on with life.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Acked-by: Ping Cheng <ping.cheng@wacom.com>

commit 567b4d71484ec67fb6432cebd4c4048da5979a2c
Author: Ping Cheng <pingc@wacom.com>
Date:   Wed May 2 14:10:15 2018 -0700

    xsetwacom: update man page for button mapping
    
    Mapping a button to 0 is to disable it in X.
    
    Signed-off-by: Ping Cheng <ping.cheng@wacom.com>

commit 11451194e36fc3ae78d5d908310c4f7d09fc783c
Author: Aaron Armstrong Skomra <skomra@gmail.com>
Date:   Mon Mar 19 14:28:19 2018 -0700

    release.sh: bugfixes
    
    1. Use correct filename variable (tarbz2 not tarball).
    2. Insert spaces into heredoc to make links work for Gmail users.
    3. The script greps the module url to see if it contains an
       approved repository. The first update to the release script
       contained a list of many approved repositories. Subsequent updates
       during the review process had these extra repositories removed.
       (git update-index --assume-unchanged release.sh can be used to
       temporarily use a different repository.) That second change
       removed
               -e "linuxwacom/.*" (Github)
       instead of
               -e "/linuxwacom/.*" (Sourceforge).
       Remove the slash which is not found in the Github path.
    4. Remove the language about xorg, mesa, etc. from error message.
    5. Correct release.sh script documentation. The release.sh script no
       longer has a `--user` option. The username is now provided as a
       required argument of the `--github` and `--sourceforge` options.
       Note that when using `--github`, a personal access token may need
       to be appended to the username with a colon if two-factor auth is
       used.
    
    Fixes: 4c17c6a0dd ("Update release.sh script from Xorg") in the tags.
    Fixes: 32c065ae02 ("add Github to release.sh script")
    Signed-off-by: Aaron Armstrong Skomra <skomra@gmail.com>
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 9d83956c2aa72b9d8744fa57e28ba5fe7f1af0f4
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Mon Mar 19 13:40:21 2018 -0700

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

commit 25d765a543ea21d6fa686f16f55d475ad0f2d13b
Author: Aaron Armstrong Skomra <skomra@gmail.com>
Date:   Tue Mar 13 10:27:24 2018 -0700

    Update README to reflect the move to Github.
    
    Signed-off-by: Aaron Armstrong Skomra <skomra@gmail.com>
    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

commit a197cc5e04c778022a78c010a22c9602591b7c2b
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Mon Mar 12 09:53:07 2018 -0700

    Fail the Coverity build if their script cannot be downloaded
    
    If curl encounters an error trying to download the Coverity build script
    (as seems to be happening at the moment due to SSL issues), we will not
    be notified since the pipe swallows the error code. This is not ideal, so
    this commit updates the Travis build steps to use a slightly more contrived
    construction which will get and then execute the script as independent steps.
    Also, to ensure curl returns an error code even in less-severe cases (e.g. a
    basic 404 "Not Found") we add the '-f' option.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

commit 414ee8130dd8b04512f38b7d9d29ecce3e30a86e
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Tue Feb 13 09:06:38 2018 -0800

    Check both valid and working state when finding new channels
    
    The usbChooseChannel function is responsible for finding the channel
    that should be used to contain a sequence of events for a particular
    tool/contact. If a tool/contact is already using a particular channel
    (i.e., the last event in the channel has the correct device type, serial
    number, and is in proximity) then usbChooseChannel will return that
    channel. Otherwise, usbChooseChannel will try to find a free channel
    (i.e., one which is out of proximity) to be used to store the tool's
    sequence of events.
    
    The existing logic has a subtle bug that may result in a malfunction
    when a specific condition occurs. In particular, if a multitouch report
    from the kernel contains an existing contact going up followed by a
    brand new contact, then usbChooseChannel will see the channel associated
    with the former contact as free and begin using it to store data for the
    new contact. As a result, the "up" event is never sent and can lead to
    further strange touch behavior (including the effective disabling of
    touch input).
    
    To fix this, we modify usbChooseChannel to consider the "valid" state as
    well as the working state when finding a new channel. A channel should
    not be considered free if its valid state is still in prox, since this
    indicates that the channel has *just* left prox. Note that we cannot
    rely on only checking the valid state since this fails in the opposite
    way: usbChooseChannel would not notice when a channel has *just* entered
    prox and would overwrite its contents.
    
    It isn't obvious wether it is also necessary to check the valid state
    for the other two cases in this function (finding an existing channel
    and forcefully clearing channels when out of space). The existing code
    seems to work, however, so we will leave it as-is.
    
    Ref: https://sourceforge.net/p/linuxwacom/bugs/335/?limit=25&page=1#73fe
    Ref: https://sourceforge.net/p/linuxwacom/bugs/339/#f940
    Ref: https://sourceforge.net/p/linuxwacom/bugs/349/
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

commit 0c27df7057c94dea4edece3c3e1462ac2a19b7a5
Author: Daniel Ferguson <danielferguson@me.com>
Date:   Mon Mar 5 18:57:35 2018 +0000

    Fix tilt-y being overridden with tilt-x
    
    Refactoring in (527fa95c29) introduced a typo in wcmFilterCoord which
    resulted in the value of tilt x being assigned to tilt y.
    
    Ref: https://github.com/linuxwacom/xf86-input-wacom/issues/11
    Fixes: 527fa95c29 ("Refactor coordinate averaging to seperate function")
    Signed-off-by: Daniel Ferguson <danielferguson@me.com>
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

commit 35047a3156be05b9ebc44ad4c43e0c9b62a85a03
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Wed Jan 31 17:51:17 2018 -0800

    Support DTK-2451 and DTH-2452 on older kernels
    
    Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

commit ffb3925cc1deb5d840ad4b2ba1ab853955d959c8
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Mon Jan 22 11:58:06 2018 -0800

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

commit 32c065ae020da43dbe25ef650a9d8c496f5cbc55
Author: Aaron Armstrong Skomra <skomra@gmail.com>
Date:   Thu Jan 18 09:53:35 2018 -0800

    add Github to release.sh script
    
    Require at least 1 of Github/Sourceforge.
    
    Ref: https://github.com/linuxwacom/xf86-input-wacom/issues/10
    
    Signed-off-by: Aaron Armstrong Skomra <skomra@gmail.com>
    Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
    Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 9f05aa04124e133a74ce69c1cb7cdce267bd8b1e
Author: Aaron Armstrong Skomra <skomra@gmail.com>
Date:   Thu Jan 18 09:53:34 2018 -0800

    remove release script code from other projects
    
    Signed-off-by: Aaron Armstrong Skomra <skomra@gmail.com>
    Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>

commit 4cc67d161123774f79d5830cd87d7adddc31bf4c
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Tue Jan 9 10:42:59 2018 -0800

    wacom 0.35.99.1

commit 685850060f1cef064a90e02191d4732f275c7179
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Tue Dec 26 14:21:17 2017 -0800

    Allocate 4 buttons for stylus devices (Pro Pen 3D)
    
    The Pro Pen 3D includes a third stylus button, reported from the kernel
    as BTN_STYLUS3. Support for this event was added earlier, but the number
    of buttons allocated was not updated. This meant that although the X
    driver would properly set the button flag bit to indicate that a button
    should be sent, a userspace event wouldn't actually be sent. This commit
    increases the number of buttons allocated, causing the third button to
    emit X11 button number 8 when pressed. This button can also be configured
    through xsetwacom now that the driver allocates the correct number.
    
    Fixes: 4a96a58f26 ("Add support for kernel's new BTN_STYLUS3 event")
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Reviewed-by: Ping Cheng <ping.cheng@wacom.com>

commit 4108d97fd7d0690d1d343bc0229b68b5fb48a6fc
