| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
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
|
| |/
|
|
|
|
| |
For Surface Go and Nuvision Solo 10 Draw
Signed-off-by: Lance Geroso <gero3977@gmail.com>
|
| |\
| |
| | |
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>
|
| |
|
|
| |
Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
|
| |\
| |
| | |
Fix issues with Microsoft Surface Go tablet
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |\ \
| | |
| | | |
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>
|
| | |
| |
| |
| |
| |
| | |
We don't want to post libwacom releases to xf86-input-wacom
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
| | |
| |
| |
| | |
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
| | |
| |
| |
| |
| |
| | |
We're well and truly on github now
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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>
|
