Commit 025bcc1 performed cleanup work on the 'wacom_pl_irq' function, making
it follow the standards used in the rest of the codebase. The change
unintiontionally allowed the function to send input events from reports
that are not marked as being in prox. This can cause problems as the
report values for X, Y, etc. are not guaranteed to be correct. In
particular, occasionally the tablet will send a report with these values
set to zero. If such a report is received it can caus an unexpected jump
in the XY position.
This patch surrounds more of the processing code with a proximity check,
preventing these zeroed reports from overwriting the current state. To
be safe, only the tool type and ABS_MISC events should be reported when
the pen is marked as being out of prox.
Fixes: 025bcc1540 ("HID: wacom: Simplify 'wacom_pl_irq'")
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit 345857b ("HID: wacom: generic: Add support for sensor offsets") included
a change to the operation and location of the call to 'wacom_add_shared_data'
in 'wacom_parse_and_register'. The modifications included moving it higher up
so that it would occur before the call to 'wacom_retrieve_hid_descriptor'. This
was done to prevent a crash that would have occured when the report containing
tablet offsets was fed into the driver with 'wacom_hid_report_raw_event'
(specifically: the various 'wacom_wac_*_report' functions were written with the
assumption that they would only be called once tablet setup had completed;
'wacom_wac_pen_report' in particular dereferences 'shared' which wasn't yet
allocated).
Moving the call to 'wacom_add_shared_data' effectively prevented the crash but
also broke the sibiling detection code which assumes that the HID descriptor
has been read and the various device_type flags set.
To fix this situation, we restore the original 'wacom_add_shared_data'
operation and location and instead implement an alternative change that can
also prevent the crash. Specifically, we notice that the report functions
mentioned above expect to be called only for input reports. By adding a check,
we can prevent feature reports (such as the offset report) from
causing trouble.
Fixes: 345857bb49 ("HID: wacom: generic: Add support for sensor offsets")
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Tested-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
post input_sync only when there are input events posted
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-By: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Make sure everything reported from pad are registered
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-By: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Sometime valid events may not be supported by the driver yet. Make
sure we don't process them when the code is not ready.
This fix prevents a kernel panic due to unsupported HID events.
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-By: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
It is unnecessary to return a value since nothing is expecting a
value from it.
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-By: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The eraser end of the 8K pen available for the MobileStudio Pro has a tool
ID of 0x84a. The 'wacom_intuos_get_tool_type' function does not currently
recognize this ID, causing it to return BTN_TOOL_PEN rather than
BTN_TOOL_RUBBER. This does not cause a problem for the MobileStudio Pro
since, as a HID_GENERIC device, the driver relies on the state of the
HID_DG_INVERT usage instead. It would, however, cause problems if the pen
is used with devices that use the traditional 'wacom_intuos_irq' codepath
instead.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This is trying to clear the lower 32 bits but the type is wrong so it
clears everything.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The HID specification that the MobileStudio Pro follows includes usages
for several values that would be good to support so that future devices
"just work" out of the box. Extend the HID_GENERIC pad codepath to handle
these usages.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Adds support for usages that may appear on the pen or pad interface which
report the state of the tablet battery.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
As with usages for the pen, the Custom HID specificiation includes
usages for the pad. Here we add functions to map and handle most
of the pad usages present on the MobileStudio Pro.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Many of Wacom's display tablets include an "outbound" area where pen
digitizing is possible but outside of the display area. To accommodate
such sensors in the HID_GENERIC codepath, we add support for the
necessary vendor-defined HID feature usages and adjust the min/max
values of the X and Y axes accordingly, similar to what is done in
the non-generic codepath.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Many of Wacom's display tablets include an "outbound" area where pen
digitizing is possible but outside of the display area. To ensure that
pen coordinates are mapped to the correct on-screen location, the driver
sets the minimum and maximum axis values of X and Y to those coordinates
which coincide with the screen edge. These values are simply the
hardware minimum/maximum plus/minus the outbound size for a particular
edge.
When outbound support was added/updated in ac414da, fa77034, and
ecd618d, we decided to have the wacom_features structs store the desired
minimum and maximum values directly. In hindsight, this was perhaps not
the best choice since it has allowed minor errors to crop up unnoticed.
Some tablets have had their coordinates over-corrected (e.g. most of the
devices "fixed" in ecd618d were already adjusted in ac414da), while
others never had a correction applied (e.g. the ISDv5 325, whose
declared maximum the hardware maximum instead of the outbound maximum).
A less error-prone method of handling the outbound is to let the driver
calculate the correct minimum/maximum values by providing it with both
the actual hardware maximums and the size of the outbound on each edge.
These values are more easy to verify as correct since the values can be
trivially compared against specifications.
This patch reverts the declared maximum values to the actual hardware
maximums, e.g. as declared prior to ac414da (values for these and other
display tablets that were subsuquently introduced have been verified
against specs). Per-edge outbound sizes are stored in the wacom_features
struct as offset_{left,right,top,bottom} and used in combination with
the hardware ranges to calculate effective axis ranges for ABS_X and
ABS_Y.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Devices following the new Custom HID mode specification (as well as even
some recent component sensors which use the same standard HID usage)
are capable of reporting tool ID information that we need to relay to
userspace. This patch adds support for reading and relaying the tool
type information, which is (unfortunately) split across two usages.
We also advertise the existence of tool types beyond BTN_TOOL_PEN
that might be available.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The 'wacom_intuos_inout' function incorrectly assmebles tool IDs from the
proximity report, shifting the higher values of the ID four bits farther
than intended. This problem was not detected until too late, but has not
caused any issues since the incorrect IDs still fit in a 32-bit integer
and userspace programs have not required the value to match the hardware
(just that the values are unique and constant).
The tool IDs reported by the new MobileStudio Pro (or any future
HID_GENERIC device that supports them) do not suffer from the same
assembly issue, however. In order for 'wacom_intuos_get_tool_type' to
work for with both codepaths, we correct this issue internally and
have 'wacom_intuos_general' only mangle the ID when it is posted to
userspace.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Wacom's professional tablets beginning with the Intuos4 are capable of
reporting an intermediate degree of proximity where the pen is no longer
close enough to communicate with ("in prox"), but still close enough to
be sensed ("in range"). This additional state is particularly useful for
performing palm rejection as it allows the driver to disable the touch
sensor while the pen is a greater distance from the tablet.
Like other professional tablets, the new MobileStudio Pro also reports
this intermeidate "in range" proximity state. Its descriptor assigns
usage 0xff0d0036 to this bit. Normally 'wacom_equivalent_usage' would
translate this to the standard HID "Quality" usage, but since this has
a different meaning we have it explicitly ignore the usage and define
it ourselves as "Sense" (since "In Range" is already defined by the
HID standard and interpreted by our driver as meaning "in prox").
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The airbrush fingerwheel does not have a usage that corresponds cleanly
with a standard HID usage, so we add explicit support for it via its
vendor-defined usage.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The vendor-defined 0xFF0D01032 ("Distance") usage is nearly equivalent to
HID_GD_Z, except that the axis direction is inverted. Unlike HID_GD_Z which
increases in value as the pen-to-surface distance is decreased, this usage
decreases. Treat this usage as a special case to ensure we don't invert the
scale to be ABS_DISTANCE compatible like we do for HID_GD_Z.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Wacom's new "MobileStudio Pro" tablets are the first devices in their
branded product line-up to include a usable HID descriptor for the pen
interface. Like prior branded products, the device can operate in one
of two modes: 'Standard HID', and 'Wacom Custom HID'. Although the
first mode is usable by the HID_GENERIC codepath as-is (huzzah!), it is
subject to some restrictions -- most notably pressure being limited
to 2048 levels instead of 8192. To ensure tablets that include support
for Custom HID mode work optimally, we add support for its usages and
switch the device to Custom HID mode if possible.
The usages defined for Custom HID mode are often numerically similar to
their standard HID equivalents, allowing us to write a simple translation
function that takes arbitrary HID usages as input and which returns
the corresponding standard HID usage as output (if one exists). Switching
on this translated usage instead of the actual usage allows the existing
cases to apply to both modes of operation without having to explicitly
define every Custom HID usage.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The HID standard defines usages that allow digitizers to report the pen's
height, tilt, and rotation and which are used by Wacom's new "MobileStudio
Pro" devices.
Note that 'hidinput_calc_abs_res' expects ABS_Z (historically used by our
driver to report twist) to have linear units. To ensure it calculates a
resolution with the actually-angular units provided in the HID descriptor
we nedd to lie and tell it we're calculating it for the (rotational) ABS_RZ
axis instead.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This just centralizes the logic used in both wacom_setup_numbered_buttons
and wacom_report_numbered_buttons so that they don't drift out of sync.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Our loose use of "pen" and "digitizer" in the naming of several of our
vendor-defined usages may be a source of confusion given that the terms
have specific meaning within the HID specification. "Pen" specifically
refers to "an integrated display that allows the use of a stylus" (e.g.
something like a tablet PC or Cintiq) wheras "Digitizer" is a better
fit for opaque tablets like an Intuos.
While we're at it, go ahead and rename the definitions to make them more
distinct and better match up with the convention used by HID (e.g. the use
of '_UP_' for usage pages) and make them more distinct.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
If a touchscreen contains both multitouch and single-touch reports in its
descriptor in that order, the driver may overwrite information it saved
about the format of the multitouch report. This can cause the report
processing code to get tripped up and send an incorrect event stream to
userspace.
In particular, this can cause last_slot_field to be overwritten with the
result that the driver prematurely assumes it has finished processing a
slot and sending the ABS_MT_SLOT event at the wrong point in time,
associating events for the current contact with the following contact
instead.
To prevent this from occurring, we update the value of last_slot_field
durring the pre_report phase to ensure that it is correct for the report
that is to be processed.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Touch arbitration is always on in wacom.ko. However, there are
touch enabled applications use both pen and touch simultaneously.
We should provide an option for userland to decide if they want
arbitration on or off.
This patch sets default touch_arbitration to on since most userland
apps are not ready to process pen and touch events simultaneously.
In the future, when userland is ready to accept pen and touch events
together, we will switch default touch_arbitration to off.
Tested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The 'oVid' and 'oPid' variables used by wacom_are_sibling are a hacky
solution to the problem of the driver historically having few good
heuristics to use in determining if two devices should be considered
siblings or not. While it works well enough for explicitly supported
devices, it offers no help for HID_GENERIC devices. Now that we have
a bit more information (e.g. direct/indirect) available to us though,
we should make use of it it to improve the pairing of such devices.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
"Direct" input devices like Cintiqs and Tablet PCs set the INPUT_PROP_DIRECT
property to notify userspace that the sensor and screen are overlaid. This
information can also be useful elsewhere within the kernel driver, however,
so we introduce a new WACOM_DEVICETYPE_DIRECT that signals this to other
kernel code.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The 24HD has 1 button per LED (first three buttons of each group).
We need a special treatment for them as it's not a uniq button that
switches between the LEDs.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The code for 21UX2 and 24HD makes the LED group 1 on the left, and
the group 0 on the right. The buttons are ordered in the other way,
but libwacom already exports those that way. So we simply can't reassign
LED group 0 to the left buttons, and have to quirk the incoming data...
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The EKR switches the LED directly, and there is no point in having
userspace handling the switch it self when it's easy enough to do
in the kernel.
The other benefit is that now userspace does not need to have root access
to the LED but need only to read them with user privileges.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Previously, all the remotes attached to the same receiver would share the
same power_supply. That's not good as the remotes will constantly change
the battery information according to their own state.
To have something generic enough, we introduce struct wacom_battery
which regroups all the information we need for a battery.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Thanks to devres, we can now afford to create more than one input node
without having to overload the remove/failure paths. Having one input
node per remote is something which should have been implemented from start
but the probability of having users with several remotes is quite low.
Anyway, still, better looking at the future and implement things properly.
Remote input nodes will be freed/unregistered magically as they are
created in the devres group &remote->remotes[index].
We need to open the hid node now that the remotes are dynamically
allocated.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
No functional changes, just a prep patch for the one after.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
If we want to have one input device per remote, it's better to have our
own struct wacom_remote which is dynamically allocated.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
wacom_remote_status_irq() sends information of addition/removal of EKR.
We want to allocate one input node per remote, so better having this
in a separate worker, not handled in the IRQ directly.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We need to add an action to ensure wacom->led.groups is null when
wacom_led_control() gets called after the resources has been freed.
This also prevents to send a LED command when there is no support
from the device.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We currently have a complex clean_inputs() function while this can be
handled all by devres. Set a group that we can destroy in wireless_work().
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Looks like the battery hijacked the wireless worker. That's not fair so
use a work queue per task.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Since fd5f92b ("HID: wacom: reuse wacom_parse_and_register() in
wireless_work"), wacom->shared->type is not set.
Send the information of the battery if we have one.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit 7e12978 ("HID: wacom: break out wacom_intuos_get_tool_type") by accident
removed stylus_in_proximity flag for Intuos series while shuffling the code
around.
Fix that by reintroducing that flag setting in wacom_intuos_inout(), where
it originally was.
Fixes: 7e12978 ("HID: wacom: break out wacom_intuos_get_tool_type")
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The fuzz present on the distance and tilt axes is noticable when a puck is
present, and userspace (specifically libinput) would like the ability to
filter out the noise. To facilitate this, we assign a fuzz value of '1'
for the distance and tilt axes. This is large enough to cover most of the
natural variation in distance value as the puck is moved around, and
enough to cover the jitter in rotation (reported through tilt axes) when
the puck is left alone.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Looks like recent changes in the Wacom driver made the Bamboo ONE crashes.
The tablet behaves as if it was a regular Bamboo device with pen, touch
and pad, but there is no physical pad connected to it.
The weird part is that the pad is still sending events and given that
there is no input node connected to it, we get anull pointer exception.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1317116
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Allow to reuse the code in a later series and simplifies
the reading of wacom_intuos_inout().
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
INTUOSHT2 in range event is not used to indicate in proximity state.
INTUOSHT2 only has one stylus.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
stylus_in_proximity was introduced to support touch arbitration
before in range was supported. With in range event, the logic
changed. stylus_in_proximity should be set for both in prox and
in range events.
To finish a clean touch arbitration logic, we should send touch
up (if it was down) before posting any general pen events.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Move general events related data validation to wacom_intuos_general.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Move wacom_intuos_schedule_prox_event inside wacom_intuos_general
so we don't call it when general event data isn't ready.
Signed-off-by: Ping Cheng <pingc@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
