linux-toradex.git/drivers/hid/wacom_sys.c, branch v4.10

HID: wacom: Fix sibling detection regression

2017-01-19T13:19:25+00:00

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 
Tested-by: Ping Cheng 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: wacom: generic: Add support for sensor offsets

2016-10-20T07:54:00+00:00

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 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: wacom: generic: Support and use 'Custom HID' mode and usages

2016-10-20T07:53:57+00:00

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 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: wacom: generic: Strip off excessive name prefixing

2016-10-20T07:53:56+00:00

The product name received from the string descriptor in the new MobileStudio
Pro line of tablets begins with "Wacom", which leads to unnecessary visual
noise in the device name when appended to the vendor name which also includes
"Wacom". Look for and fix cases like this.

Signed-off-by: Jason Gerecke 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: wacom: Detect and correct descriptors missing HID_DG_BARRELSWITCH2

2016-10-20T07:53:56+00:00

ISDv4 devices have long supported reporting data from each of two barrel
switches, but HID_DG_BARRELSWITCH2 itself was only recently standardized.
Prior to its adoption, ISDv4 devices would associate the bit indicating
the state of the second barrel switch with the "Undefined" 0x000D0000
usage. Although most such devices have explicit support, a few use the
HID_GENERIC codepath which ignores the "Undefined" usage.

This patch adds code which detects the presence of a pre-standard second
barrel switch and corrects the usage value so that the HID_GENERIC code
will declare its presence and report its state.

Signed-off-by: Jason Gerecke 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: wacom: Update vendor-defined usage names to better match standards

2016-10-20T07:53:54+00:00

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 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: wacom: Augment 'oVid' and 'oPid' with heuristics for HID_GENERIC

2016-08-10T09:44:28+00:00

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 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: wacom: power_supply: provide the actual model_name

2016-08-05T11:39:23+00:00

Instead of displaying a generic "tablet", now g-c-c shows a pretty
"Wacom Intuos Pro S (WL)".

Signed-off-by: Benjamin Tissoires 
Acked-by: Ping Cheng 
Signed-off-by: Jiri Kosina

HID: wacom: power_supply: remove ac information

2016-08-05T11:39:22+00:00

Looks like upowerd is ignoring this since October 2013, so there is
no need to keep this around in the kernel.
And as mentioned in 8aaa592 (linux: Ignore ACs coming from devices) in
the upower tree, "We already have enough information on the device
battery".

Signed-off-by: Benjamin Tissoires 
Acked-by: Ping Cheng 
Signed-off-by: Jiri Kosina

HID: wacom: power_supply: mark the type as USB

2016-08-05T11:39:21+00:00

When upowerd detects a new device, it tries to map this new device to
an input to guess its kind. It works OK for wired tablets when the
wireless module and its battery are attached, but not so well when
connected over wireless.
In that case, the battery is attached to the wireless HID node, not
the Pen or Pad HID node. So there is no input node as a parent of the
reported battery, which means it will be showed as a computer battery
in gnome-control-center.

If we set the power supply type to USB, upowerd has a heuristic that
detects "wacom_" in the name of the power_supply, and set the type to
tablet. So it's now clear that the reported battery of from a tablet.
(see https://cgit.freedesktop.org/upower/tree/src/linux/up-device-supply.c)

Signed-off-by: Benjamin Tissoires 
Acked-by: Ping Cheng 
Signed-off-by: Jiri Kosina