From: Jason Gerecke <hidden> Date: 2016-10-06 21:22:40
Wacom announced two new "MobileStudio Pro" tablets yesterday, a third
iteration of the Cintiq Companion line of mobile PCs which can double
as external pen displays.
Unlike Wacom's prior professional-grade devices, the HID descriptor for
the MobileStudio Pro includes a rudimentary (but standard!) "Digitizer"
application collection that is usable by the existing HID_GENERIC codepath.
Additionally, a second vendor-defined application collection exists which
fully defines reports that enable full tablet functionality. The numerous
vendor-defined usages are planned to be used in future professional devices
as well, allowing us to finally gain some of the same forward compatibility
benefits we've had for ISDv4 devices since 3.17.
* Patches 1-3 perform some basic cleanups.
* Patches 4-6 work on the operation of the driver for all HID_GENERIC
devices, correcting minor issues and adding some missing features.
* Patches 7-19 implement support for the vendor defined usages that
are used in the MobileStudio Pro, and which are planned to be used
in future professional devices as well.
Jiri: Could you let me know whether it would be possible to schedule
these for the currently-open 4.9 merge window?
Jason Gerecke (19):
HID: wacom: Update vendor-defined usage names to better match
standards
HID: wacom: Have WACOM_PEN_FIELD and WACOM_FINGER_FIELD recgonize more
fields
HID: wacom: Refactor button-to-key translation into function
HID: wacom: Detect and correct descriptors missing
HID_DG_BARRELSWITCH2
HID: wacom: generic: Strip off excessive name prefixing
HID: wacom: generic: Add support for height, tilt, and twist usages
HID: wacom: generic: Support and use 'Custom HID' mode and usages
HID: wacom: generic: Add support for vendor-defined "Distance" usage
HID: wacom: generic: Add support for vendor-defined "Fingerwheel"
usage
HID: wacom: generic: Add support for vendor-defined "Sense" usage
HID: wacom: Read and internally use corrected Intuos tool IDs
HID: wacom: generic: Support tool ID and additional tool types
HID: wacom: generic: Pass 'hdev' to 'wacom_map_usage'
HID: wacom: Fix sensor outbounds and redefine as offsets from each
edge
HID: wacom: generic: Add support for sensor offsets
HID: wacom: generic: Introduce pad support
HID: wacom: generic: Add support for battery status on pen and pad
interfaces
HID: wacom: generic: Extend pad support
HID: input: Recognize ABS_WHEEL in hidinput_calc_abs_res
drivers/hid/hid-input.c | 1 +
drivers/hid/wacom_sys.c | 92 ++++++--
drivers/hid/wacom_wac.c | 544 +++++++++++++++++++++++++++++++++++++++---------
drivers/hid/wacom_wac.h | 73 ++++++-
include/linux/hid.h | 4 +
5 files changed, 595 insertions(+), 119 deletions(-)
--
2.10.0
From: Jason Gerecke <hidden> Date: 2016-10-06 21:22:43
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>
---
drivers/hid/wacom_sys.c | 12 ++++++------
drivers/hid/wacom_wac.c | 2 +-
drivers/hid/wacom_wac.h | 17 +++++++++--------
3 files changed, 16 insertions(+), 15 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-06 21:22:44
We've defined several new usages (e.g. WACOM_G9_PEN and WACOM_G9_TOUCHSCREEN)
which aren't checked by the WACOM_PEN_FIELD and WACOM_FINGER_FIELD macros but
probably should be.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
---
drivers/hid/wacom_wac.h | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-06 21:22:46
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>
---
drivers/hid/wacom_wac.c | 36 ++++++++++++++++++++++++------------
1 file changed, 24 insertions(+), 12 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-06 21:22:47
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 <jason.gerecke@wacom.com>
---
drivers/hid/wacom_sys.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
From: Jason Gerecke <hidden> Date: 2016-10-06 21:22:49
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 <jason.gerecke@wacom.com>
---
drivers/hid/wacom_sys.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
From: Jason Gerecke <hidden> Date: 2016-10-06 21:22:50
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>
---
drivers/hid/wacom_wac.c | 28 ++++++++++++++++++++++++++--
include/linux/hid.h | 3 +++
2 files changed, 29 insertions(+), 2 deletions(-)
@@ -1508,8 +1525,15 @@ static int wacom_wac_pen_event(struct hid_device *hdev, struct hid_field *field,structwacom_wac*wacom_wac=&wacom->wacom_wac;structinput_dev*input=wacom_wac->pen_input;-/* checking which Tool / tip switch to send */switch(usage->hid){+caseHID_GD_Z:+/*+*HID_GD_Z"should increase as the control's position is+*movedfromhightolow", while ABS_DISTANCE instead+*increasesinvalueasthetoolmovesfromlowtohigh.+*/+value=field->logical_maximum-value;+break;caseHID_DG_INRANGE:wacom_wac->hid_data.inrange_state=value;return0;
From: Jason Gerecke <hidden> Date: 2016-10-06 21:22:52
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>
---
drivers/hid/wacom_sys.c | 5 +++++
drivers/hid/wacom_wac.c | 37 +++++++++++++++++++++++++++++++------
drivers/hid/wacom_wac.h | 3 +++
3 files changed, 39 insertions(+), 6 deletions(-)
@@ -1524,8 +1546,9 @@ static int wacom_wac_pen_event(struct hid_device *hdev, struct hid_field *field,structwacom*wacom=hid_get_drvdata(hdev);structwacom_wac*wacom_wac=&wacom->wacom_wac;structinput_dev*input=wacom_wac->pen_input;+unsignedequivalent_usage=wacom_equivalent_usage(usage->hid);-switch(usage->hid){+switch(equivalent_usage){caseHID_GD_Z:/**HID_GD_Z"should increase as the control's position is
From: Jason Gerecke <hidden> Date: 2016-10-06 21:22:53
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>
---
drivers/hid/wacom_wac.c | 4 +++-
drivers/hid/wacom_wac.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
From: Jason Gerecke <hidden> Date: 2016-10-06 21:22:55
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>
---
drivers/hid/wacom_wac.c | 3 +++
drivers/hid/wacom_wac.h | 1 +
2 files changed, 4 insertions(+)
From: Jason Gerecke <hidden> Date: 2016-10-06 21:22:56
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>
---
drivers/hid/wacom_wac.c | 26 +++++++++++++++++++++++---
drivers/hid/wacom_wac.h | 3 +++
2 files changed, 26 insertions(+), 3 deletions(-)
@@ -1572,6 +1581,9 @@ static int wacom_wac_pen_event(struct hid_device *hdev, struct hid_field *field,caseHID_DG_TIPSWITCH:wacom_wac->hid_data.tipswitch|=value;return0;+caseWACOM_HID_WD_SENSE:+wacom_wac->hid_data.sense_state=value;+return0;}/* send pen events only when touch is up or forced out
@@ -1580,6 +1592,10 @@ static int wacom_wac_pen_event(struct hid_device *hdev, struct hid_field *field,if(!usage->type||delay_pen_events(wacom_wac))return0;+/* send pen events only when the pen is in/entering/leaving proximity */+if(!wacom_wac->hid_data.inrange_state&&!wacom_wac->tool[0])+return0;+input_event(input,usage->type,usage->code,value);return0;
@@ -1598,16 +1614,17 @@ static void wacom_wac_pen_report(struct hid_device *hdev,structwacom_wac*wacom_wac=&wacom->wacom_wac;structinput_dev*input=wacom_wac->pen_input;boolprox=wacom_wac->hid_data.inrange_state;+boolrange=wacom_wac->hid_data.sense_state;-if(!wacom_wac->shared->stylus_in_proximity)/* first in prox */+if(!wacom_wac->tool[0]&&prox)/* first in prox *//* Going into proximity select tool */wacom_wac->tool[0]=wacom_wac->hid_data.invert_state?BTN_TOOL_RUBBER:BTN_TOOL_PEN;/* keep pen state for touch events */-wacom_wac->shared->stylus_in_proximity=prox;+wacom_wac->shared->stylus_in_proximity=range;-if(!delay_pen_events(wacom_wac)){+if(!delay_pen_events(wacom_wac)&&wacom_wac->tool[0]){input_report_key(input,BTN_TOUCH,wacom_wac->hid_data.tipswitch);input_report_key(input,wacom_wac->tool[0],prox);
From: Jason Gerecke <hidden> Date: 2016-10-06 21:22:58
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>
---
drivers/hid/wacom_wac.c | 38 ++++++++++++++++++++++----------------
1 file changed, 22 insertions(+), 16 deletions(-)
@@ -693,7 +698,7 @@ static int wacom_intuos_inout(struct wacom_wac *wacom)(data[6]<<4)+(data[7]>>4);wacom->id[idx]=(data[2]<<4)|(data[3]>>4)|-((data[7]&0x0f)<<20)|((data[8]&0xf0)<<12);+((data[7]&0x0f)<<16)|((data[8]&0xf0)<<8);wacom->tool[idx]=wacom_intuos_get_tool_type(wacom->id[idx]);
@@ -923,7 +928,7 @@ static int wacom_intuos_general(struct wacom_wac *wacom)*don'treporteventsforinvaliddata*//* older I4 styli don't work with new Cintiqs */-if((!((wacom->id[idx]>>20)&0x01)&&+if((!((wacom->id[idx]>>16)&0x01)&&(features->type==WACOM_21UX2))||/* Only large Intuos support Lense Cursor */(wacom->tool[idx]==BTN_TOOL_LENS&&
@@ -1059,7 +1064,8 @@ static int wacom_intuos_general(struct wacom_wac *wacom)break;}-input_report_abs(input,ABS_MISC,wacom->id[idx]);/* report tool id */+input_report_abs(input,ABS_MISC,+wacom_intuos_id_mangle(wacom->id[idx]));/* report tool id */input_report_key(input,wacom->tool[idx],1);input_event(input,EV_MSC,MSC_SERIAL,wacom->serial[idx]);wacom->reporting_data=true;
From: Jason Gerecke <hidden> Date: 2016-10-06 21:22:59
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>
---
drivers/hid/wacom_wac.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++---
drivers/hid/wacom_wac.h | 4 ++-
2 files changed, 71 insertions(+), 5 deletions(-)
@@ -1587,9 +1600,35 @@ static int wacom_wac_pen_event(struct hid_device *hdev, struct hid_field *field,caseHID_DG_TIPSWITCH:wacom_wac->hid_data.tipswitch|=value;return0;+caseHID_DG_TOOLSERIALNUMBER:+wacom_wac->serial[0]=(wacom_wac->serial[0]&~0xFFFFFFFF);+wacom_wac->serial[0]|=value;+return0;caseWACOM_HID_WD_SENSE:wacom_wac->hid_data.sense_state=value;return0;+caseWACOM_HID_WD_SERIALHI:+wacom_wac->serial[0]=(wacom_wac->serial[0]&0xFFFFFFFF);+wacom_wac->serial[0]|=((__u64)value)<<32;+/*+*Non-USIEMRdevicesmaycontainadditionaltooltype+*informationhere.SeeWACOM_HID_WD_TOOLTYPEcasefor+*moredetails.+*/+if(value>>20==1){+wacom_wac->id[0]|=value&0xFFFFF;+}+return0;+caseWACOM_HID_WD_TOOLTYPE:+/*+*Somedevices(MobileStudioPro,andpossiblylater+*devicesaswell)donotreturnthecompletetool+*typeintheirWACOM_HID_WD_TOOLTYPEusage.Usea+*bitwiseORsothecompletevaluecanbebuilt+*upovertime:(+*/+wacom_wac->id[0]|=value;+return0;}/* send pen events only when touch is up or forced out
@@ -1622,26 +1661,51 @@ static void wacom_wac_pen_report(struct hid_device *hdev,boolprox=wacom_wac->hid_data.inrange_state;boolrange=wacom_wac->hid_data.sense_state;-if(!wacom_wac->tool[0]&&prox)/* first in prox */+if(!wacom_wac->tool[0]&&prox){/* first in prox *//* Going into proximity select tool */-wacom_wac->tool[0]=wacom_wac->hid_data.invert_state?-BTN_TOOL_RUBBER:BTN_TOOL_PEN;+if(wacom_wac->hid_data.invert_state)+wacom_wac->tool[0]=BTN_TOOL_RUBBER;+elseif(wacom_wac->id[0])+wacom_wac->tool[0]=wacom_intuos_get_tool_type(wacom_wac->id[0]);+else+wacom_wac->tool[0]=BTN_TOOL_PEN;+}/* keep pen state for touch events */wacom_wac->shared->stylus_in_proximity=range;if(!delay_pen_events(wacom_wac)&&wacom_wac->tool[0]){+intid=wacom_wac->id[0];++/*+*Non-USIEMRtoolsshouldhavetheirIDsmangledto+*matchthelegacybehaviorofwacom_intuos_general+*/+if(wacom_wac->serial[0]>>52==1)+id=wacom_intuos_id_mangle(id);++/*+*Toensurecompatibilitywithxf86-input-wacom,weshould+*reporttheBTN_TOOL_*eventpriortotheABS_MISCor+*MSC_SERIALevents.+*/input_report_key(input,BTN_TOUCH,wacom_wac->hid_data.tipswitch);input_report_key(input,wacom_wac->tool[0],prox);+if(wacom_wac->serial[0]){+input_event(input,EV_MSC,MSC_SERIAL,wacom_wac->serial[0]);+input_report_abs(input,ABS_MISC,id);+}wacom_wac->hid_data.tipswitch=false;input_sync(input);}-if(!prox)+if(!prox){wacom_wac->tool[0]=0;+wacom_wac->id[0]=0;+}}staticvoidwacom_wac_finger_usage_mapping(structhid_device*hdev,
From: Jason Gerecke <hidden> Date: 2016-10-06 21:23:01
In the following "Add support for sensor offsets" patch we'll need access
to the 'features' struct within 'wacom_map_usage', so update the function
signature and calls to include a reference to the HID device so this can
be done.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
---
drivers/hid/wacom_wac.c | 53 ++++++++++++++++++++++++++-----------------------
1 file changed, 28 insertions(+), 25 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-06 21:23:02
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>
---
drivers/hid/wacom_wac.c | 62 ++++++++++++++++++++++++++++++++-----------------
drivers/hid/wacom_wac.h | 6 +++--
2 files changed, 45 insertions(+), 23 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-06 21:23:04
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>
---
drivers/hid/wacom_sys.c | 38 ++++++++++++++++++++++++++++++--------
drivers/hid/wacom_wac.c | 38 ++++++++++++++++++++++++++++++++++++++
drivers/hid/wacom_wac.h | 4 ++++
3 files changed, 72 insertions(+), 8 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-06 21:23:05
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>
---
drivers/hid/wacom_wac.c | 143 ++++++++++++++++++++++++++++++++++++++++++------
drivers/hid/wacom_wac.h | 19 +++++++
2 files changed, 146 insertions(+), 16 deletions(-)
@@ -41,6 +41,8 @@ MODULE_PARM_DESC(touch_arbitration, " on (Y) off (N)");staticvoidwacom_report_numbered_buttons(structinput_dev*input_dev,intbutton_count,intmask);+staticintwacom_numbered_button_to_key(intn);+/**PercentofbatterycapacityforGraphire.*8thvaluemeansAConlineandshow100%capacity.
@@ -1447,12 +1449,16 @@ static int wacom_equivalent_usage(int usage)intsubpage=(usage&0xFF00)<<8;intsubusage=(usage&0xFF);-if(subpage==WACOM_HID_SP_DIGITIZER||+if(subpage==WACOM_HID_SP_PAD||+subpage==WACOM_HID_SP_BUTTON||+subpage==WACOM_HID_SP_DIGITIZER||subpage==WACOM_HID_SP_DIGITIZERINFO||usage==WACOM_HID_WD_SENSE||usage==WACOM_HID_WD_SERIALHI||usage==WACOM_HID_WD_TOOLTYPE||-usage==WACOM_HID_WD_DISTANCE){+usage==WACOM_HID_WD_DISTANCE||+usage==WACOM_HID_WD_TOUCHRING||+usage==WACOM_HID_WD_TOUCHRINGSTATUS){returnusage;}
@@ -2594,6 +2696,8 @@ void wacom_setup_device_quirks(struct wacom *wacom)structwacom_features*features=&wacom->wacom_wac.features;/* The pen and pad share the same interface on most devices */+if(features->numbered_buttons>0)+features->device_type|=WACOM_DEVICETYPE_PAD;if(features->type==GRAPHIRE_BT||features->type==WACOM_G4||features->type==DTUS||(features->type>=INTUOS3S&&features->type<=WACOM_MO)){
@@ -3115,8 +3219,12 @@ int wacom_setup_pad_input_capabilities(struct input_dev *input_dev,__set_bit(ABS_MISC,input_dev->absbit);/* kept for making legacy xf86-input-wacom accepting the pad */-input_set_abs_params(input_dev,ABS_X,0,1,0,0);-input_set_abs_params(input_dev,ABS_Y,0,1,0,0);+if(!(input_dev->absinfo&&(input_dev->absinfo[ABS_X].minimum||+input_dev->absinfo[ABS_X].maximum)))+input_set_abs_params(input_dev,ABS_X,0,1,0,0);+if(!(input_dev->absinfo&&(input_dev->absinfo[ABS_Y].minimum||+input_dev->absinfo[ABS_Y].maximum)))+input_set_abs_params(input_dev,ABS_Y,0,1,0,0);/* kept for making udev and libwacom accepting the pad */__set_bit(BTN_STYLUS,input_dev->keybit);
@@ -3236,6 +3344,9 @@ int wacom_setup_pad_input_capabilities(struct input_dev *input_dev,input_set_abs_params(input_dev,ABS_WHEEL,0,71,0,0);break;+caseHID_GENERIC:+break;+default:/* no pad supported */return-ENODEV;
From: Jason Gerecke <hidden> Date: 2016-10-06 21:23:07
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>
---
drivers/hid/wacom_wac.c | 41 ++++++++++++++++++++++++++++++++++++++++-
drivers/hid/wacom_wac.h | 6 ++++++
include/linux/hid.h | 1 +
3 files changed, 47 insertions(+), 1 deletion(-)
From: Jason Gerecke <hidden> Date: 2016-10-06 21:23:08
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>
---
drivers/hid/wacom_wac.c | 15 +++++++++++++++
drivers/hid/wacom_wac.h | 5 +++++
2 files changed, 20 insertions(+)
From: Jason Gerecke <hidden> Date: 2016-10-06 21:23:09
The "Steering" usage (HID_UP_SIMULATION | 0xc8) is defined in HUT 1.12 as
follows:
"A steering wheel is a single degree-of-freedom device that rotates about
an axis. The zero position is always the neutral or 'straight ahead'
position, with positive values turning clockwise and negative values
turning counterclockwise. If the Coordinate Values Wrap attribute is
set, the steering wheel can be turned past 360 degrees."
The hidinput_configure_usage function canonically maps this usage to the
ABS_WHEEL axis, but hidinput_calc_abs_res does not recognize this axis
as one for which it can calculate a resolution. This effectively prevents
wheels from being assigned a proper resolution that userspace can use
to determine the precise angle of input.
This commit adds ABS_WHEEL as a rotational axis to hidinput_calc_abs_res.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
---
drivers/hid/hid-input.c | 1 +
1 file changed, 1 insertion(+)
From: Benjamin Tissoires <hidden> Date: 2016-10-07 15:41:26
On Oct 06 2016 or thereabouts, Jason Gerecke wrote:
Wacom announced two new "MobileStudio Pro" tablets yesterday, a third
iteration of the Cintiq Companion line of mobile PCs which can double
as external pen displays.
Unlike Wacom's prior professional-grade devices, the HID descriptor for
the MobileStudio Pro includes a rudimentary (but standard!) "Digitizer"
application collection that is usable by the existing HID_GENERIC codepath.
Additionally, a second vendor-defined application collection exists which
fully defines reports that enable full tablet functionality. The numerous
vendor-defined usages are planned to be used in future professional devices
as well, allowing us to finally gain some of the same forward compatibility
benefits we've had for ISDv4 devices since 3.17.
* Patches 1-3 perform some basic cleanups.
* Patches 4-6 work on the operation of the driver for all HID_GENERIC
devices, correcting minor issues and adding some missing features.
* Patches 7-19 implement support for the vendor defined usages that
are used in the MobileStudio Pro, and which are planned to be used
in future professional devices as well.
Jiri: Could you let me know whether it would be possible to schedule
these for the currently-open 4.9 merge window?
Jiri, FYI, I have already made 2 (or 3) internal reviews of this series.
I just have one/two nitpicks here and there (I noticed few if statements
with braces while only one statement was done after), but nothing
preventing from pulling the series IMO.
I have been staring the series for too long now, and I can't find
anything useful (besides in patch 13, but not a biggy).
From what I can tell, the series has little impact on existing devices
(patches 1, 3, 11, 14), and I assume Jason and the other Wacom engineers
made extensive tests for these patches.
Patch 19 for hid-input should also be safe :)
The series is:
Reviewed-by: Benjamin Tissoires <redacted>
Cheers,
Benjamin
Jason Gerecke (19):
HID: wacom: Update vendor-defined usage names to better match
standards
HID: wacom: Have WACOM_PEN_FIELD and WACOM_FINGER_FIELD recgonize more
fields
HID: wacom: Refactor button-to-key translation into function
HID: wacom: Detect and correct descriptors missing
HID_DG_BARRELSWITCH2
HID: wacom: generic: Strip off excessive name prefixing
HID: wacom: generic: Add support for height, tilt, and twist usages
HID: wacom: generic: Support and use 'Custom HID' mode and usages
HID: wacom: generic: Add support for vendor-defined "Distance" usage
HID: wacom: generic: Add support for vendor-defined "Fingerwheel"
usage
HID: wacom: generic: Add support for vendor-defined "Sense" usage
HID: wacom: Read and internally use corrected Intuos tool IDs
HID: wacom: generic: Support tool ID and additional tool types
HID: wacom: generic: Pass 'hdev' to 'wacom_map_usage'
HID: wacom: Fix sensor outbounds and redefine as offsets from each
edge
HID: wacom: generic: Add support for sensor offsets
HID: wacom: generic: Introduce pad support
HID: wacom: generic: Add support for battery status on pen and pad
interfaces
HID: wacom: generic: Extend pad support
HID: input: Recognize ABS_WHEEL in hidinput_calc_abs_res
drivers/hid/hid-input.c | 1 +
drivers/hid/wacom_sys.c | 92 ++++++--
drivers/hid/wacom_wac.c | 544 +++++++++++++++++++++++++++++++++++++++---------
drivers/hid/wacom_wac.h | 73 ++++++-
include/linux/hid.h | 4 +
5 files changed, 595 insertions(+), 119 deletions(-)
--
2.10.0
From: Benjamin Tissoires <hidden> Date: 2016-10-07 15:47:00
On Oct 06 2016 or thereabouts, Jason Gerecke wrote:
quoted hunk
In the following "Add support for sensor offsets" patch we'll need access
to the 'features' struct within 'wacom_map_usage', so update the function
signature and calls to include a reference to the HID device so this can
be done.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
---
drivers/hid/wacom_wac.c | 53 ++++++++++++++++++++++++++-----------------------
1 file changed, 28 insertions(+), 25 deletions(-)
@@ -1465,9 +1465,12 @@ static int wacom_equivalent_usage(int usage)returnusage;}-staticvoidwacom_map_usage(structinput_dev*input,structhid_usage*usage,-structhid_field*field,__u8type,__u16code,intfuzz)+staticvoidwacom_map_usage(structinput_dev*input,structhid_device*hdev,+structhid_usage*usage,structhid_field*field,__u8type,+__u16code,intfuzz){+structwacom*wacom=hid_get_drvdata(hdev);
This might not be entirely relevant, but given the inputs are created
through wacom_allocate_input() and struct wacom * being stored in the
driver data, a simple call to input_get_drvdata(input) would provide the
struct wacom. Then from here, the hid_device can be retrieved from
struct wacom directly.
So I don't know if it's worth resending the series just for this and if
this has caveats... (my rev-by still applies).
Cheers,
Benjamin
quoted hunk
+ struct wacom_wac *wacom_wac = &wacom->wacom_wac; int fmin = field->logical_minimum; int fmax = field->logical_maximum; unsigned int equivalent_usage = wacom_equivalent_usage(usage->hid);
From: Jason Gerecke <hidden> Date: 2016-10-07 20:54:08
On 10/07/2016 08:46 AM, Benjamin Tissoires wrote:
On Oct 06 2016 or thereabouts, Jason Gerecke wrote:
quoted
In the following "Add support for sensor offsets" patch we'll need access
to the 'features' struct within 'wacom_map_usage', so update the function
signature and calls to include a reference to the HID device so this can
be done.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
---
drivers/hid/wacom_wac.c | 53 ++++++++++++++++++++++++++-----------------------
1 file changed, 28 insertions(+), 25 deletions(-)
@@ -1465,9 +1465,12 @@ static int wacom_equivalent_usage(int usage)returnusage;}-staticvoidwacom_map_usage(structinput_dev*input,structhid_usage*usage,-structhid_field*field,__u8type,__u16code,intfuzz)+staticvoidwacom_map_usage(structinput_dev*input,structhid_device*hdev,+structhid_usage*usage,structhid_field*field,__u8type,+__u16code,intfuzz){+structwacom*wacom=hid_get_drvdata(hdev);
This might not be entirely relevant, but given the inputs are created
through wacom_allocate_input() and struct wacom * being stored in the
driver data, a simple call to input_get_drvdata(input) would provide the
struct wacom. Then from here, the hid_device can be retrieved from
struct wacom directly.
So I don't know if it's worth resending the series just for this and if
this has caveats... (my rev-by still applies).
Cheers,
Benjamin
I'd be happy with dropping this patch and using input_get_drvdata
instead. I hadn't remotely considered that we could access the wacom
structure from there as well. As noisy as it might be, I'll send a V2
with your rev-by and the change.
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
quoted
+ struct wacom_wac *wacom_wac = &wacom->wacom_wac; int fmin = field->logical_minimum; int fmax = field->logical_maximum; unsigned int equivalent_usage = wacom_equivalent_usage(usage->hid);
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
We've defined several new usages (e.g. WACOM_G9_PEN and WACOM_G9_TOUCHSCREEN)
which aren't checked by the WACOM_PEN_FIELD and WACOM_FINGER_FIELD macros but
probably should be.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <redacted>
---
drivers/hid/wacom_wac.h | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <redacted>
---
drivers/hid/wacom_wac.c | 28 ++++++++++++++++++++++++++--
include/linux/hid.h | 3 +++
2 files changed, 29 insertions(+), 2 deletions(-)
@@ -1508,8 +1525,15 @@ static int wacom_wac_pen_event(struct hid_device *hdev, struct hid_field *field,structwacom_wac*wacom_wac=&wacom->wacom_wac;structinput_dev*input=wacom_wac->pen_input;-/* checking which Tool / tip switch to send */switch(usage->hid){+caseHID_GD_Z:+/*+*HID_GD_Z"should increase as the control's position is+*movedfromhightolow", while ABS_DISTANCE instead+*increasesinvalueasthetoolmovesfromlowtohigh.+*/+value=field->logical_maximum-value;+break;caseHID_DG_INRANGE:wacom_wac->hid_data.inrange_state=value;return0;
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <redacted>
---
drivers/hid/wacom_wac.c | 36 ++++++++++++++++++++++++------------
1 file changed, 24 insertions(+), 12 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <redacted>
---
drivers/hid/wacom_wac.c | 143 ++++++++++++++++++++++++++++++++++++++++++------
drivers/hid/wacom_wac.h | 19 +++++++
2 files changed, 146 insertions(+), 16 deletions(-)
@@ -41,6 +41,8 @@ MODULE_PARM_DESC(touch_arbitration, " on (Y) off (N)");staticvoidwacom_report_numbered_buttons(structinput_dev*input_dev,intbutton_count,intmask);+staticintwacom_numbered_button_to_key(intn);+/**PercentofbatterycapacityforGraphire.*8thvaluemeansAConlineandshow100%capacity.
@@ -1447,12 +1449,16 @@ static int wacom_equivalent_usage(int usage)intsubpage=(usage&0xFF00)<<8;intsubusage=(usage&0xFF);-if(subpage==WACOM_HID_SP_DIGITIZER||+if(subpage==WACOM_HID_SP_PAD||+subpage==WACOM_HID_SP_BUTTON||+subpage==WACOM_HID_SP_DIGITIZER||subpage==WACOM_HID_SP_DIGITIZERINFO||usage==WACOM_HID_WD_SENSE||usage==WACOM_HID_WD_SERIALHI||usage==WACOM_HID_WD_TOOLTYPE||-usage==WACOM_HID_WD_DISTANCE){+usage==WACOM_HID_WD_DISTANCE||+usage==WACOM_HID_WD_TOUCHRING||+usage==WACOM_HID_WD_TOUCHRINGSTATUS){returnusage;}
@@ -2593,6 +2695,8 @@ void wacom_setup_device_quirks(struct wacom *wacom)structwacom_features*features=&wacom->wacom_wac.features;/* The pen and pad share the same interface on most devices */+if(features->numbered_buttons>0)+features->device_type|=WACOM_DEVICETYPE_PAD;if(features->type==GRAPHIRE_BT||features->type==WACOM_G4||features->type==DTUS||(features->type>=INTUOS3S&&features->type<=WACOM_MO)){
@@ -3114,8 +3218,12 @@ int wacom_setup_pad_input_capabilities(struct input_dev *input_dev,__set_bit(ABS_MISC,input_dev->absbit);/* kept for making legacy xf86-input-wacom accepting the pad */-input_set_abs_params(input_dev,ABS_X,0,1,0,0);-input_set_abs_params(input_dev,ABS_Y,0,1,0,0);+if(!(input_dev->absinfo&&(input_dev->absinfo[ABS_X].minimum||+input_dev->absinfo[ABS_X].maximum)))+input_set_abs_params(input_dev,ABS_X,0,1,0,0);+if(!(input_dev->absinfo&&(input_dev->absinfo[ABS_Y].minimum||+input_dev->absinfo[ABS_Y].maximum)))+input_set_abs_params(input_dev,ABS_Y,0,1,0,0);/* kept for making udev and libwacom accepting the pad */__set_bit(BTN_STYLUS,input_dev->keybit);
@@ -3235,6 +3343,9 @@ int wacom_setup_pad_input_capabilities(struct input_dev *input_dev,input_set_abs_params(input_dev,ABS_WHEEL,0,71,0,0);break;+caseHID_GENERIC:+break;+default:/* no pad supported */return-ENODEV;
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <redacted>
---
drivers/hid/wacom_wac.c | 26 +++++++++++++++++++++++---
drivers/hid/wacom_wac.h | 3 +++
2 files changed, 26 insertions(+), 3 deletions(-)
@@ -1572,6 +1581,9 @@ static int wacom_wac_pen_event(struct hid_device *hdev, struct hid_field *field,caseHID_DG_TIPSWITCH:wacom_wac->hid_data.tipswitch|=value;return0;+caseWACOM_HID_WD_SENSE:+wacom_wac->hid_data.sense_state=value;+return0;}/* send pen events only when touch is up or forced out
@@ -1580,6 +1592,10 @@ static int wacom_wac_pen_event(struct hid_device *hdev, struct hid_field *field,if(!usage->type||delay_pen_events(wacom_wac))return0;+/* send pen events only when the pen is in/entering/leaving proximity */+if(!wacom_wac->hid_data.inrange_state&&!wacom_wac->tool[0])+return0;+input_event(input,usage->type,usage->code,value);return0;
@@ -1598,16 +1614,17 @@ static void wacom_wac_pen_report(struct hid_device *hdev,structwacom_wac*wacom_wac=&wacom->wacom_wac;structinput_dev*input=wacom_wac->pen_input;boolprox=wacom_wac->hid_data.inrange_state;+boolrange=wacom_wac->hid_data.sense_state;-if(!wacom_wac->shared->stylus_in_proximity)/* first in prox */+if(!wacom_wac->tool[0]&&prox)/* first in prox *//* Going into proximity select tool */wacom_wac->tool[0]=wacom_wac->hid_data.invert_state?BTN_TOOL_RUBBER:BTN_TOOL_PEN;/* keep pen state for touch events */-wacom_wac->shared->stylus_in_proximity=prox;+wacom_wac->shared->stylus_in_proximity=range;-if(!delay_pen_events(wacom_wac)){+if(!delay_pen_events(wacom_wac)&&wacom_wac->tool[0]){input_report_key(input,BTN_TOUCH,wacom_wac->hid_data.tipswitch);input_report_key(input,wacom_wac->tool[0],prox);
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <redacted>
---
drivers/hid/wacom_sys.c | 5 +++++
drivers/hid/wacom_wac.c | 37 +++++++++++++++++++++++++++++++------
drivers/hid/wacom_wac.h | 3 +++
3 files changed, 39 insertions(+), 6 deletions(-)
@@ -1524,8 +1546,9 @@ static int wacom_wac_pen_event(struct hid_device *hdev, struct hid_field *field,structwacom*wacom=hid_get_drvdata(hdev);structwacom_wac*wacom_wac=&wacom->wacom_wac;structinput_dev*input=wacom_wac->pen_input;+unsignedequivalent_usage=wacom_equivalent_usage(usage->hid);-switch(usage->hid){+switch(equivalent_usage){caseHID_GD_Z:/**HID_GD_Z"should increase as the control's position is
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <redacted>
---
drivers/hid/wacom_wac.c | 62 ++++++++++++++++++++++++++++++++-----------------
drivers/hid/wacom_wac.h | 6 +++--
2 files changed, 45 insertions(+), 23 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <redacted>
---
drivers/hid/wacom_sys.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <redacted>
---
drivers/hid/wacom_sys.c | 12 ++++++------
drivers/hid/wacom_wac.c | 2 +-
drivers/hid/wacom_wac.h | 17 +++++++++--------
3 files changed, 16 insertions(+), 15 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <redacted>
---
drivers/hid/wacom_sys.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <redacted>
---
drivers/hid/wacom_wac.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++---
drivers/hid/wacom_wac.h | 4 ++-
2 files changed, 71 insertions(+), 5 deletions(-)
@@ -1587,9 +1600,35 @@ static int wacom_wac_pen_event(struct hid_device *hdev, struct hid_field *field,caseHID_DG_TIPSWITCH:wacom_wac->hid_data.tipswitch|=value;return0;+caseHID_DG_TOOLSERIALNUMBER:+wacom_wac->serial[0]=(wacom_wac->serial[0]&~0xFFFFFFFF);+wacom_wac->serial[0]|=value;+return0;caseWACOM_HID_WD_SENSE:wacom_wac->hid_data.sense_state=value;return0;+caseWACOM_HID_WD_SERIALHI:+wacom_wac->serial[0]=(wacom_wac->serial[0]&0xFFFFFFFF);+wacom_wac->serial[0]|=((__u64)value)<<32;+/*+*Non-USIEMRdevicesmaycontainadditionaltooltype+*informationhere.SeeWACOM_HID_WD_TOOLTYPEcasefor+*moredetails.+*/+if(value>>20==1){+wacom_wac->id[0]|=value&0xFFFFF;+}+return0;+caseWACOM_HID_WD_TOOLTYPE:+/*+*Somedevices(MobileStudioPro,andpossiblylater+*devicesaswell)donotreturnthecompletetool+*typeintheirWACOM_HID_WD_TOOLTYPEusage.Usea+*bitwiseORsothecompletevaluecanbebuilt+*upovertime:(+*/+wacom_wac->id[0]|=value;+return0;}/* send pen events only when touch is up or forced out
@@ -1622,26 +1661,51 @@ static void wacom_wac_pen_report(struct hid_device *hdev,boolprox=wacom_wac->hid_data.inrange_state;boolrange=wacom_wac->hid_data.sense_state;-if(!wacom_wac->tool[0]&&prox)/* first in prox */+if(!wacom_wac->tool[0]&&prox){/* first in prox *//* Going into proximity select tool */-wacom_wac->tool[0]=wacom_wac->hid_data.invert_state?-BTN_TOOL_RUBBER:BTN_TOOL_PEN;+if(wacom_wac->hid_data.invert_state)+wacom_wac->tool[0]=BTN_TOOL_RUBBER;+elseif(wacom_wac->id[0])+wacom_wac->tool[0]=wacom_intuos_get_tool_type(wacom_wac->id[0]);+else+wacom_wac->tool[0]=BTN_TOOL_PEN;+}/* keep pen state for touch events */wacom_wac->shared->stylus_in_proximity=range;if(!delay_pen_events(wacom_wac)&&wacom_wac->tool[0]){+intid=wacom_wac->id[0];++/*+*Non-USIEMRtoolsshouldhavetheirIDsmangledto+*matchthelegacybehaviorofwacom_intuos_general+*/+if(wacom_wac->serial[0]>>52==1)+id=wacom_intuos_id_mangle(id);++/*+*Toensurecompatibilitywithxf86-input-wacom,weshould+*reporttheBTN_TOOL_*eventpriortotheABS_MISCor+*MSC_SERIALevents.+*/input_report_key(input,BTN_TOUCH,wacom_wac->hid_data.tipswitch);input_report_key(input,wacom_wac->tool[0],prox);+if(wacom_wac->serial[0]){+input_event(input,EV_MSC,MSC_SERIAL,wacom_wac->serial[0]);+input_report_abs(input,ABS_MISC,id);+}wacom_wac->hid_data.tipswitch=false;input_sync(input);}-if(!prox)+if(!prox){wacom_wac->tool[0]=0;+wacom_wac->id[0]=0;+}}staticvoidwacom_wac_finger_usage_mapping(structhid_device*hdev,
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <redacted>
---
drivers/hid/wacom_wac.c | 3 +++
drivers/hid/wacom_wac.h | 1 +
2 files changed, 4 insertions(+)
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <redacted>
---
drivers/hid/wacom_wac.c | 41 ++++++++++++++++++++++++++++++++++++++++-
drivers/hid/wacom_wac.h | 6 ++++++
include/linux/hid.h | 1 +
3 files changed, 47 insertions(+), 1 deletion(-)
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <redacted>
---
drivers/hid/wacom_wac.c | 38 ++++++++++++++++++++++----------------
1 file changed, 22 insertions(+), 16 deletions(-)
@@ -693,7 +698,7 @@ static int wacom_intuos_inout(struct wacom_wac *wacom)(data[6]<<4)+(data[7]>>4);wacom->id[idx]=(data[2]<<4)|(data[3]>>4)|-((data[7]&0x0f)<<20)|((data[8]&0xf0)<<12);+((data[7]&0x0f)<<16)|((data[8]&0xf0)<<8);wacom->tool[idx]=wacom_intuos_get_tool_type(wacom->id[idx]);
@@ -923,7 +928,7 @@ static int wacom_intuos_general(struct wacom_wac *wacom)*don'treporteventsforinvaliddata*//* older I4 styli don't work with new Cintiqs */-if((!((wacom->id[idx]>>20)&0x01)&&+if((!((wacom->id[idx]>>16)&0x01)&&(features->type==WACOM_21UX2))||/* Only large Intuos support Lense Cursor */(wacom->tool[idx]==BTN_TOOL_LENS&&
@@ -1059,7 +1064,8 @@ static int wacom_intuos_general(struct wacom_wac *wacom)break;}-input_report_abs(input,ABS_MISC,wacom->id[idx]);/* report tool id */+input_report_abs(input,ABS_MISC,+wacom_intuos_id_mangle(wacom->id[idx]));/* report tool id */input_report_key(input,wacom->tool[idx],1);input_event(input,EV_MSC,MSC_SERIAL,wacom->serial[idx]);wacom->reporting_data=true;
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <redacted>
---
Changes from v1:
* Use input_get_drvdata instead of hid_get_drvdata. This removes the
need for a "Pass 'hdev' to 'wacom_map_usage'" patch, which is no
longer part of the v2 set.
drivers/hid/wacom_sys.c | 38 ++++++++++++++++++++++++++++++--------
drivers/hid/wacom_wac.c | 40 ++++++++++++++++++++++++++++++++++++++++
drivers/hid/wacom_wac.h | 4 ++++
3 files changed, 74 insertions(+), 8 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
The "Steering" usage (HID_UP_SIMULATION | 0xc8) is defined in HUT 1.12 as
follows:
"A steering wheel is a single degree-of-freedom device that rotates about
an axis. The zero position is always the neutral or 'straight ahead'
position, with positive values turning clockwise and negative values
turning counterclockwise. If the Coordinate Values Wrap attribute is
set, the steering wheel can be turned past 360 degrees."
The hidinput_configure_usage function canonically maps this usage to the
ABS_WHEEL axis, but hidinput_calc_abs_res does not recognize this axis
as one for which it can calculate a resolution. This effectively prevents
wheels from being assigned a proper resolution that userspace can use
to determine the precise angle of input.
This commit adds ABS_WHEEL as a rotational axis to hidinput_calc_abs_res.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <redacted>
---
drivers/hid/hid-input.c | 1 +
1 file changed, 1 insertion(+)
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <redacted>
---
drivers/hid/wacom_wac.c | 4 +++-
drivers/hid/wacom_wac.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
From: Jason Gerecke <hidden> Date: 2016-10-07 22:18:01
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 <redacted>
---
drivers/hid/wacom_wac.c | 15 +++++++++++++++
drivers/hid/wacom_wac.h | 5 +++++
2 files changed, 20 insertions(+)
@@ -1711,7 +1736,7 @@ static int wacom_wac_finger_event(struct hid_device *hdev, if (usage->usage_index + 1 == field->report_count) {- if (usage->hid == wacom_wac->features.last_slot_field)+ if (equivalent_usage == wacom_wac->features.last_slot_field)
What tree is this based on please? In all the codebase I have,
last_slot_field is a member field of wacom_wac's hid_data, not a member of
struct wacom_features.
--
Jiri Kosina
SUSE Labs
From: Jason Gerecke <hidden> Date: 2016-10-18 17:09:49
On 10/18/2016 08:26 AM, Jiri Kosina wrote:
On Fri, 7 Oct 2016, Jason Gerecke wrote:
quoted
@@ -1711,7 +1736,7 @@ static int wacom_wac_finger_event(struct hid_device *hdev, if (usage->usage_index + 1 == field->report_count) {- if (usage->hid == wacom_wac->features.last_slot_field)+ if (equivalent_usage == wacom_wac->features.last_slot_field)
What tree is this based on please? In all the codebase I have,
last_slot_field is a member field of wacom_wac's hid_data, not a member of
struct wacom_features.
This was based on your for-4.9/wacom tree, whose tip (for me) was commit
1924e05 ("HID: wacom - add touch_arbitration parameter to wacom module").
It looks like my tree only has commit 601a22f ("HID: wacom: Report input
events for each finger on generic devices") but not commit 003f50a
("HID: wacom: Update last_slot_field during pre_report phase"). Not sure
why though.
What would you like me to do?
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
if (usage->usage_index + 1 == field->report_count) {- if (usage->hid == wacom_wac->features.last_slot_field)+ if (equivalent_usage == wacom_wac->features.last_slot_field)
What tree is this based on please? In all the codebase I have,
last_slot_field is a member field of wacom_wac's hid_data, not a member of
struct wacom_features.
This was based on your for-4.9/wacom tree, whose tip (for me) was commit
1924e05 ("HID: wacom - add touch_arbitration parameter to wacom module").
It looks like my tree only has commit 601a22f ("HID: wacom: Report input
events for each finger on generic devices")
Pardon me? That commit is from 2014 (3.19-rc1). It really shouldn't be
used as a basis for a development.
but not commit 003f50a ("HID: wacom: Update last_slot_field during
pre_report phase").
That's a commit that went in for 4.9-rc1 (authored by you).
Not sure why though.
What would you like me to do?
Dunno where the confusion is coming from really. Could you please just
rebase the patchset on top of something up to date (such as or Linus'
git, master branch in my tree, or whatnot), and resubmit?
Thanks,
--
Jiri Kosina
SUSE Labs
From: Jason Gerecke <hidden> Date: 2016-10-20 01:04:06
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 <redacted>
---
drivers/hid/wacom_sys.c | 12 ++++++------
drivers/hid/wacom_wac.c | 2 +-
drivers/hid/wacom_wac.h | 17 +++++++++--------
3 files changed, 16 insertions(+), 15 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-20 01:04:09
We've defined several new usages (e.g. WACOM_G9_PEN and WACOM_G9_TOUCHSCREEN)
which aren't checked by the WACOM_PEN_FIELD and WACOM_FINGER_FIELD macros but
probably should be.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <redacted>
---
drivers/hid/wacom_wac.h | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-20 01:04:13
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 <redacted>
---
drivers/hid/wacom_wac.c | 36 ++++++++++++++++++++++++------------
1 file changed, 24 insertions(+), 12 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-20 01:04:18
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 <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <redacted>
---
drivers/hid/wacom_sys.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
From: Jason Gerecke <hidden> Date: 2016-10-20 01:04:22
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 <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <redacted>
---
drivers/hid/wacom_sys.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
From: Jason Gerecke <hidden> Date: 2016-10-20 01:04:27
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 <redacted>
---
drivers/hid/wacom_wac.c | 28 ++++++++++++++++++++++++++--
include/linux/hid.h | 3 +++
2 files changed, 29 insertions(+), 2 deletions(-)
@@ -1508,8 +1525,15 @@ static int wacom_wac_pen_event(struct hid_device *hdev, struct hid_field *field,structwacom_wac*wacom_wac=&wacom->wacom_wac;structinput_dev*input=wacom_wac->pen_input;-/* checking which Tool / tip switch to send */switch(usage->hid){+caseHID_GD_Z:+/*+*HID_GD_Z"should increase as the control's position is+*movedfromhightolow", while ABS_DISTANCE instead+*increasesinvalueasthetoolmovesfromlowtohigh.+*/+value=field->logical_maximum-value;+break;caseHID_DG_INRANGE:wacom_wac->hid_data.inrange_state=value;return0;
From: Jason Gerecke <hidden> Date: 2016-10-20 01:04:32
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 <redacted>
---
drivers/hid/wacom_sys.c | 5 +++++
drivers/hid/wacom_wac.c | 37 +++++++++++++++++++++++++++++++------
drivers/hid/wacom_wac.h | 3 +++
3 files changed, 39 insertions(+), 6 deletions(-)
@@ -1524,8 +1546,9 @@ static int wacom_wac_pen_event(struct hid_device *hdev, struct hid_field *field,structwacom*wacom=hid_get_drvdata(hdev);structwacom_wac*wacom_wac=&wacom->wacom_wac;structinput_dev*input=wacom_wac->pen_input;+unsignedequivalent_usage=wacom_equivalent_usage(usage->hid);-switch(usage->hid){+switch(equivalent_usage){caseHID_GD_Z:/**HID_GD_Z"should increase as the control's position is
From: Jason Gerecke <hidden> Date: 2016-10-20 01:04:36
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 <redacted>
---
drivers/hid/wacom_wac.c | 4 +++-
drivers/hid/wacom_wac.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
From: Jason Gerecke <hidden> Date: 2016-10-20 01:04:42
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 <redacted>
---
drivers/hid/wacom_wac.c | 3 +++
drivers/hid/wacom_wac.h | 1 +
2 files changed, 4 insertions(+)
From: Jason Gerecke <hidden> Date: 2016-10-20 01:04:46
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 <redacted>
---
drivers/hid/wacom_wac.c | 26 +++++++++++++++++++++++---
drivers/hid/wacom_wac.h | 3 +++
2 files changed, 26 insertions(+), 3 deletions(-)
@@ -1572,6 +1581,9 @@ static int wacom_wac_pen_event(struct hid_device *hdev, struct hid_field *field,caseHID_DG_TIPSWITCH:wacom_wac->hid_data.tipswitch|=value;return0;+caseWACOM_HID_WD_SENSE:+wacom_wac->hid_data.sense_state=value;+return0;}/* send pen events only when touch is up or forced out
@@ -1580,6 +1592,10 @@ static int wacom_wac_pen_event(struct hid_device *hdev, struct hid_field *field,if(!usage->type||delay_pen_events(wacom_wac))return0;+/* send pen events only when the pen is in/entering/leaving proximity */+if(!wacom_wac->hid_data.inrange_state&&!wacom_wac->tool[0])+return0;+input_event(input,usage->type,usage->code,value);return0;
@@ -1598,16 +1614,17 @@ static void wacom_wac_pen_report(struct hid_device *hdev,structwacom_wac*wacom_wac=&wacom->wacom_wac;structinput_dev*input=wacom_wac->pen_input;boolprox=wacom_wac->hid_data.inrange_state;+boolrange=wacom_wac->hid_data.sense_state;-if(!wacom_wac->shared->stylus_in_proximity)/* first in prox */+if(!wacom_wac->tool[0]&&prox)/* first in prox *//* Going into proximity select tool */wacom_wac->tool[0]=wacom_wac->hid_data.invert_state?BTN_TOOL_RUBBER:BTN_TOOL_PEN;/* keep pen state for touch events */-wacom_wac->shared->stylus_in_proximity=prox;+wacom_wac->shared->stylus_in_proximity=range;-if(!delay_pen_events(wacom_wac)){+if(!delay_pen_events(wacom_wac)&&wacom_wac->tool[0]){input_report_key(input,BTN_TOUCH,wacom_wac->hid_data.tipswitch);input_report_key(input,wacom_wac->tool[0],prox);
From: Jason Gerecke <hidden> Date: 2016-10-20 01:04:51
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 <redacted>
---
drivers/hid/wacom_wac.c | 38 ++++++++++++++++++++++----------------
1 file changed, 22 insertions(+), 16 deletions(-)
@@ -693,7 +698,7 @@ static int wacom_intuos_inout(struct wacom_wac *wacom)(data[6]<<4)+(data[7]>>4);wacom->id[idx]=(data[2]<<4)|(data[3]>>4)|-((data[7]&0x0f)<<20)|((data[8]&0xf0)<<12);+((data[7]&0x0f)<<16)|((data[8]&0xf0)<<8);wacom->tool[idx]=wacom_intuos_get_tool_type(wacom->id[idx]);
@@ -923,7 +928,7 @@ static int wacom_intuos_general(struct wacom_wac *wacom)*don'treporteventsforinvaliddata*//* older I4 styli don't work with new Cintiqs */-if((!((wacom->id[idx]>>20)&0x01)&&+if((!((wacom->id[idx]>>16)&0x01)&&(features->type==WACOM_21UX2))||/* Only large Intuos support Lense Cursor */(wacom->tool[idx]==BTN_TOOL_LENS&&
@@ -1059,7 +1064,8 @@ static int wacom_intuos_general(struct wacom_wac *wacom)break;}-input_report_abs(input,ABS_MISC,wacom->id[idx]);/* report tool id */+input_report_abs(input,ABS_MISC,+wacom_intuos_id_mangle(wacom->id[idx]));/* report tool id */input_report_key(input,wacom->tool[idx],1);input_event(input,EV_MSC,MSC_SERIAL,wacom->serial[idx]);wacom->reporting_data=true;
From: Jason Gerecke <hidden> Date: 2016-10-20 01:04:55
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 <redacted>
---
drivers/hid/wacom_wac.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++---
drivers/hid/wacom_wac.h | 4 ++-
2 files changed, 71 insertions(+), 5 deletions(-)
@@ -1587,9 +1600,35 @@ static int wacom_wac_pen_event(struct hid_device *hdev, struct hid_field *field,caseHID_DG_TIPSWITCH:wacom_wac->hid_data.tipswitch|=value;return0;+caseHID_DG_TOOLSERIALNUMBER:+wacom_wac->serial[0]=(wacom_wac->serial[0]&~0xFFFFFFFF);+wacom_wac->serial[0]|=value;+return0;caseWACOM_HID_WD_SENSE:wacom_wac->hid_data.sense_state=value;return0;+caseWACOM_HID_WD_SERIALHI:+wacom_wac->serial[0]=(wacom_wac->serial[0]&0xFFFFFFFF);+wacom_wac->serial[0]|=((__u64)value)<<32;+/*+*Non-USIEMRdevicesmaycontainadditionaltooltype+*informationhere.SeeWACOM_HID_WD_TOOLTYPEcasefor+*moredetails.+*/+if(value>>20==1){+wacom_wac->id[0]|=value&0xFFFFF;+}+return0;+caseWACOM_HID_WD_TOOLTYPE:+/*+*Somedevices(MobileStudioPro,andpossiblylater+*devicesaswell)donotreturnthecompletetool+*typeintheirWACOM_HID_WD_TOOLTYPEusage.Usea+*bitwiseORsothecompletevaluecanbebuilt+*upovertime:(+*/+wacom_wac->id[0]|=value;+return0;}/* send pen events only when touch is up or forced out
@@ -1622,26 +1661,51 @@ static void wacom_wac_pen_report(struct hid_device *hdev,boolprox=wacom_wac->hid_data.inrange_state;boolrange=wacom_wac->hid_data.sense_state;-if(!wacom_wac->tool[0]&&prox)/* first in prox */+if(!wacom_wac->tool[0]&&prox){/* first in prox *//* Going into proximity select tool */-wacom_wac->tool[0]=wacom_wac->hid_data.invert_state?-BTN_TOOL_RUBBER:BTN_TOOL_PEN;+if(wacom_wac->hid_data.invert_state)+wacom_wac->tool[0]=BTN_TOOL_RUBBER;+elseif(wacom_wac->id[0])+wacom_wac->tool[0]=wacom_intuos_get_tool_type(wacom_wac->id[0]);+else+wacom_wac->tool[0]=BTN_TOOL_PEN;+}/* keep pen state for touch events */wacom_wac->shared->stylus_in_proximity=range;if(!delay_pen_events(wacom_wac)&&wacom_wac->tool[0]){+intid=wacom_wac->id[0];++/*+*Non-USIEMRtoolsshouldhavetheirIDsmangledto+*matchthelegacybehaviorofwacom_intuos_general+*/+if(wacom_wac->serial[0]>>52==1)+id=wacom_intuos_id_mangle(id);++/*+*Toensurecompatibilitywithxf86-input-wacom,weshould+*reporttheBTN_TOOL_*eventpriortotheABS_MISCor+*MSC_SERIALevents.+*/input_report_key(input,BTN_TOUCH,wacom_wac->hid_data.tipswitch);input_report_key(input,wacom_wac->tool[0],prox);+if(wacom_wac->serial[0]){+input_event(input,EV_MSC,MSC_SERIAL,wacom_wac->serial[0]);+input_report_abs(input,ABS_MISC,id);+}wacom_wac->hid_data.tipswitch=false;input_sync(input);}-if(!prox)+if(!prox){wacom_wac->tool[0]=0;+wacom_wac->id[0]=0;+}}staticvoidwacom_wac_finger_usage_mapping(structhid_device*hdev,
From: Jason Gerecke <hidden> Date: 2016-10-20 01:05:00
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 <redacted>
---
drivers/hid/wacom_wac.c | 62 ++++++++++++++++++++++++++++++++-----------------
drivers/hid/wacom_wac.h | 6 +++--
2 files changed, 45 insertions(+), 23 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-20 01:05:01
On 10/18/2016 02:39 PM, Jiri Kosina wrote:
On Tue, 18 Oct 2016, Jason Gerecke wrote:
quoted
quoted
quoted
if (usage->usage_index + 1 == field->report_count) {- if (usage->hid == wacom_wac->features.last_slot_field)+ if (equivalent_usage == wacom_wac->features.last_slot_field)
What tree is this based on please? In all the codebase I have,
last_slot_field is a member field of wacom_wac's hid_data, not a member of
struct wacom_features.
This was based on your for-4.9/wacom tree, whose tip (for me) was commit
1924e05 ("HID: wacom - add touch_arbitration parameter to wacom module").
It looks like my tree only has commit 601a22f ("HID: wacom: Report input
events for each finger on generic devices")
Pardon me? That commit is from 2014 (3.19-rc1). It really shouldn't be
used as a basis for a development.
quoted
but not commit 003f50a ("HID: wacom: Update last_slot_field during
pre_report phase").
That's a commit that went in for 4.9-rc1 (authored by you).
quoted
Not sure why though.
What would you like me to do?
Dunno where the confusion is coming from really. Could you please just
rebase the patchset on top of something up to date (such as or Linus'
git, master branch in my tree, or whatnot), and resubmit?
Thanks,
New v3 patches submitted based on your master branch.
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
From: Jason Gerecke <hidden> Date: 2016-10-20 01:05:04
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 <redacted>
---
drivers/hid/wacom_sys.c | 38 ++++++++++++++++++++++++++++++--------
drivers/hid/wacom_wac.c | 40 ++++++++++++++++++++++++++++++++++++++++
drivers/hid/wacom_wac.h | 4 ++++
3 files changed, 74 insertions(+), 8 deletions(-)
From: Jason Gerecke <hidden> Date: 2016-10-20 01:05:09
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 <redacted>
---
drivers/hid/wacom_wac.c | 143 ++++++++++++++++++++++++++++++++++++++++++------
drivers/hid/wacom_wac.h | 19 +++++++
2 files changed, 146 insertions(+), 16 deletions(-)
@@ -41,6 +41,8 @@ MODULE_PARM_DESC(touch_arbitration, " on (Y) off (N)");staticvoidwacom_report_numbered_buttons(structinput_dev*input_dev,intbutton_count,intmask);+staticintwacom_numbered_button_to_key(intn);+/**PercentofbatterycapacityforGraphire.*8thvaluemeansAConlineandshow100%capacity.
@@ -1447,12 +1449,16 @@ static int wacom_equivalent_usage(int usage)intsubpage=(usage&0xFF00)<<8;intsubusage=(usage&0xFF);-if(subpage==WACOM_HID_SP_DIGITIZER||+if(subpage==WACOM_HID_SP_PAD||+subpage==WACOM_HID_SP_BUTTON||+subpage==WACOM_HID_SP_DIGITIZER||subpage==WACOM_HID_SP_DIGITIZERINFO||usage==WACOM_HID_WD_SENSE||usage==WACOM_HID_WD_SERIALHI||usage==WACOM_HID_WD_TOOLTYPE||-usage==WACOM_HID_WD_DISTANCE){+usage==WACOM_HID_WD_DISTANCE||+usage==WACOM_HID_WD_TOUCHRING||+usage==WACOM_HID_WD_TOUCHRINGSTATUS){returnusage;}
@@ -2583,6 +2685,8 @@ void wacom_setup_device_quirks(struct wacom *wacom)structwacom_features*features=&wacom->wacom_wac.features;/* The pen and pad share the same interface on most devices */+if(features->numbered_buttons>0)+features->device_type|=WACOM_DEVICETYPE_PAD;if(features->type==GRAPHIRE_BT||features->type==WACOM_G4||features->type==DTUS||(features->type>=INTUOS3S&&features->type<=WACOM_MO)){
@@ -3104,8 +3208,12 @@ int wacom_setup_pad_input_capabilities(struct input_dev *input_dev,__set_bit(ABS_MISC,input_dev->absbit);/* kept for making legacy xf86-input-wacom accepting the pad */-input_set_abs_params(input_dev,ABS_X,0,1,0,0);-input_set_abs_params(input_dev,ABS_Y,0,1,0,0);+if(!(input_dev->absinfo&&(input_dev->absinfo[ABS_X].minimum||+input_dev->absinfo[ABS_X].maximum)))+input_set_abs_params(input_dev,ABS_X,0,1,0,0);+if(!(input_dev->absinfo&&(input_dev->absinfo[ABS_Y].minimum||+input_dev->absinfo[ABS_Y].maximum)))+input_set_abs_params(input_dev,ABS_Y,0,1,0,0);/* kept for making udev and libwacom accepting the pad */__set_bit(BTN_STYLUS,input_dev->keybit);
@@ -3225,6 +3333,9 @@ int wacom_setup_pad_input_capabilities(struct input_dev *input_dev,input_set_abs_params(input_dev,ABS_WHEEL,0,71,0,0);break;+caseHID_GENERIC:+break;+default:/* no pad supported */return-ENODEV;
From: Jason Gerecke <hidden> Date: 2016-10-20 01:05:14
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 <redacted>
---
drivers/hid/wacom_wac.c | 41 ++++++++++++++++++++++++++++++++++++++++-
drivers/hid/wacom_wac.h | 6 ++++++
include/linux/hid.h | 1 +
3 files changed, 47 insertions(+), 1 deletion(-)
From: Jason Gerecke <hidden> Date: 2016-10-20 01:05:18
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 <redacted>
---
drivers/hid/wacom_wac.c | 15 +++++++++++++++
drivers/hid/wacom_wac.h | 5 +++++
2 files changed, 20 insertions(+)
From: Jason Gerecke <hidden> Date: 2016-10-20 01:05:23
The "Steering" usage (HID_UP_SIMULATION | 0xc8) is defined in HUT 1.12 as
follows:
"A steering wheel is a single degree-of-freedom device that rotates about
an axis. The zero position is always the neutral or 'straight ahead'
position, with positive values turning clockwise and negative values
turning counterclockwise. If the Coordinate Values Wrap attribute is
set, the steering wheel can be turned past 360 degrees."
The hidinput_configure_usage function canonically maps this usage to the
ABS_WHEEL axis, but hidinput_calc_abs_res does not recognize this axis
as one for which it can calculate a resolution. This effectively prevents
wheels from being assigned a proper resolution that userspace can use
to determine the precise angle of input.
This commit adds ABS_WHEEL as a rotational axis to hidinput_calc_abs_res.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <redacted>
---
drivers/hid/hid-input.c | 1 +
1 file changed, 1 insertion(+)