| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
| |
For https://github.com/linuxwacom/xf86-input-wacom/issues/128
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| | |
|
| |\
| |
| |
| |
| | |
Support new Cintiqs for older kernels
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
|
| |/
|
|
|
|
| |
Kernels older than 2.6.38 do not report INPUT_PROP_DIRECT
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
|
| |
|
|
| |
Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
|
| |
|
|
| |
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
|
| |\
| |
| |
| |
| | |
Recognize new MobileStudio Pro PID
Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
|
| | |
| |
| |
| |
| |
| |
| | |
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>
|
| |\ \
| |/
|/| |
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>
|
| |\
| |
| |
| |
| | |
tools: Fix potential buffer overflow when reading from serial tablet
Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
| |
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
|
| |
|
|
| |
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
|
| |\
| |
| |
| |
| | |
Gesture mode default change
Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |\
| |
| |
| |
| | |
Support new MobileStudio Pro for older kernels
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
|
| |/
|
|
|
|
| |
Support new MobileStudio Pro 13 and 16
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
|
| |\
| |
| |
| |
| | |
Improve gesture recognition and usability
Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| | |
Make some especially-long lines a little easier to read.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 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>
|
| |\
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |/
|
|
| |
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
| |\
| |
| | |
Remove and replace references to Sourceforge
|
| | |
| |
| |
| |
| |
| | |
The project has moved to Github.
Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
|
| |\ \
| |/
|/| |
Add support for Surface Go and Nuvision Solo 10 Draw
|
