linux-stable.git/drivers/hid, branch v4.14.136

HID: wacom: correct touch resolution x/y typo

2019-07-31T05:28:41+00:00

commit 68c20cc2164cc5c7c73f8012ae6491afdb1f7f72 upstream.

This affects the 2nd-gen Intuos Pro Medium and Large
when using their Bluetooth connection.

Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
Cc:  # v4.11+
Signed-off-by: Aaron Armstrong Skomra 
Reviewed-by: Jason Gerecke 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: wacom: generic: only switch the mode on devices with LEDs

2019-07-31T05:28:41+00:00

commit d8e9806005f28bbb49899dab2068e3359e22ba35 upstream.

Currently, the driver will attempt to set the mode on all
devices with a center button, but some devices with a center
button lack LEDs, and attempting to set the LEDs on devices
without LEDs results in the kernel error message of the form:

"leds input8::wacom-0.1: Setting an LED's brightness failed (-32)"

This is because the generic codepath erroneously assumes that the
BUTTON_CENTER usage indicates that the device has LEDs, the
previously ignored TOUCH_RING_SETTING usage is a more accurate
indication of the existence of LEDs on the device.

Fixes: 10c55cacb8b2 ("HID: wacom: generic: support LEDs")
Cc:  # v4.11+
Signed-off-by: Aaron Armstrong Skomra 
Reviewed-by: Jason Gerecke 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: wacom: Send BTN_TOUCH in response to INTUOSP2_BT eraser contact

2019-06-22T06:16:19+00:00

commit fe7f8d73d1af19b678171170e4e5384deb57833d upstream.

The Bluetooth reports from the 2nd-gen Intuos Pro have separate bits for
indicating if the tip or eraser is in contact with the tablet. At the
moment, only the tip contact bit controls the state of the BTN_TOUCH
event. This prevents the eraser from working as expected. This commit
changes the driver to send BTN_TOUCH whenever either the tip or eraser
contact bit is set.

Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
Cc:  # 4.11+
Signed-off-by: Jason Gerecke 
Reviewed-by: Aaron Skomra 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Greg Kroah-Hartman

HID: wacom: Don't report anything prior to the tool entering range

2019-06-22T06:16:19+00:00

commit e92a7be7fe5b2510fa60965eaf25f9e3dc08b8cc upstream.

If the tool spends some time in prox before entering range, a series of
events (e.g. ABS_DISTANCE, MSC_SERIAL) can be sent before we or userspace
have any clue about the pen whose data is being reported. We need to hold
off on reporting anything until the pen has entered range. Since we still
want to report events that occur "in prox" after the pen has *left* range
we use 'wacom-tool[0]' as the indicator that the pen did at one point
enter range and provide us/userspace with tool type and serial number
information.

Fixes: a48324de6d4d ("HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range")
Cc:  # 4.11+
Signed-off-by: Jason Gerecke 
Reviewed-by: Aaron Armstrong Skomra 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Greg Kroah-Hartman

HID: wacom: Don't set tool type until we're in range

2019-06-22T06:16:19+00:00

commit 2cc08800a6b9fcda7c7afbcf2da1a6e8808da725 upstream.

The serial number and tool type information that is reported by the tablet
while a pen is merely "in prox" instead of fully "in range" can be stale
and cause us to report incorrect tool information. Serial number, tool
type, and other information is only valid once the pen comes fully in range
so we should be careful to not use this information until that point.

In particular, this issue may cause the driver to incorectly report
BTN_TOOL_RUBBER after switching from the eraser tool back to the pen.

Fixes: a48324de6d4d ("HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range")
Cc:  # 4.11+
Signed-off-by: Jason Gerecke 
Reviewed-by: Aaron Armstrong Skomra 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Greg Kroah-Hartman

HID: wacom: Sync INTUOSP2_BT touch state after each frame if necessary

2019-06-19T06:20:53+00:00

commit 69dbdfffef20c715df9f381b2cee4e9e0a4efd93 upstream.

The Bluetooth interface of the 2nd-gen Intuos Pro batches together four
independent "frames" of finger data into a single report. Each frame
is essentially equivalent to a single USB report, with the up-to-10
fingers worth of information being spread across two frames. At the
moment the driver only calls `input_sync` after processing all four
frames have been processed, which can result in the driver sending
multiple updates for a single slot within the same SYN_REPORT. This
can confuse userspace, so modify the driver to sync more often if
necessary (i.e., after reporting the state of all fingers).

Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
Cc:  # 4.11+
Signed-off-by: Jason Gerecke 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Greg Kroah-Hartman

HID: wacom: Correct button numbering 2nd-gen Intuos Pro over Bluetooth

2019-06-19T06:20:53+00:00

commit 6441fc781c344df61402be1fde582c4491fa35fa upstream.

The button numbering of the 2nd-gen Intuos Pro is not consistent between
the USB and Bluetooth interfaces. Over USB, the HID_GENERIC codepath
enumerates the eight ExpressKeys first (BTN_0 - BTN_7) followed by the
center modeswitch button (BTN_8). The Bluetooth codepath, however, has
the center modeswitch button as BTN_0 and the the eight ExpressKeys as
BTN_1 - BTN_8. To ensure userspace button mappings do not change
depending on how the tablet is connected, modify the Bluetooth codepath
to report buttons in the same order as USB.

To ensure the mode switch LED continues to toggle in response to the
mode switch button, the `wacom_is_led_toggled` function also requires
a small update.

Link: https://github.com/linuxwacom/input-wacom/pull/79
Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
Cc:  # 4.11+
Signed-off-by: Jason Gerecke 
Reviewed-by: Aaron Skomra 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Greg Kroah-Hartman

HID: logitech-hidpp: change low battery level threshold from 31 to 30 percent

2019-05-31T13:47:31+00:00

[ Upstream commit 1f87b0cd32b3456d7efdfb017fcf74d0bfe3ec29 ]

According to hidpp20_batterylevel_get_battery_info my Logitech K270
keyboard reports only 2 battery levels. This matches with what I've seen
after testing with batteries at varying level of fullness, it always
reports either 5% or 30%.

Windows reports "battery good" for the 30% level. I've captured an USB
trace of Windows reading the battery and it is getting the same info
as the Linux hidpp code gets.

Now that Linux handles these devices as hidpp devices, it reports the
battery as being low as it treats anything under 31% as low, this leads
to the user constantly getting a "Keyboard battery is low" warning from
GNOME3, which is very annoying.

This commit fixes this by changing the low threshold to anything under
30%, which I assume is what Windows does.

Signed-off-by: Hans de Goede 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: core: move Usage Page concatenation to Main item

2019-05-31T13:47:31+00:00

[ Upstream commit 58e75155009cc800005629955d3482f36a1e0eec ]

As seen on some USB wireless keyboards manufactured by Primax, the HID
parser was using some assumptions that are not always true. In this case
it's s the fact that, inside the scope of a main item, an Usage Page
will always precede an Usage.

The spec is not pretty clear as 6.2.2.7 states "Any usage that follows
is interpreted as a Usage ID and concatenated with the Usage Page".
While 6.2.2.8 states "When the parser encounters a main item it
concatenates the last declared Usage Page with a Usage to form a
complete usage value." Being somewhat contradictory it was decided to
match Window's implementation, which follows 6.2.2.8.

In summary, the patch moves the Usage Page concatenation from the local
item parsing function to the main item parsing function.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Terry Junge 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Sasha Levin

HID: logitech-hidpp: use RAP instead of FAP to get the protocol version

2019-05-31T13:47:24+00:00

[ Upstream commit 096377525cdb8251e4656085efc988bdf733fb4c ]

According to the logitech_hidpp_2.0_specification_draft_2012-06-04.pdf doc:
https://lekensteyn.nl/files/logitech/logitech_hidpp_2.0_specification_draft_2012-06-04.pdf

We should use a register-access-protocol request using the short input /
output report ids. This is necessary because 27MHz HID++ receivers have
a max-packetsize on their HIP++ endpoint of 8, so they cannot support
long reports. Using a feature-access-protocol request (which is always
long or very-long) with these will cause a timeout error, followed by
the hidpp driver treating the device as not being HID++ capable.

This commit fixes this by switching to using a rap request to get the
protocol version.

Besides being tested with a (046d:c517) 27MHz receiver with various
27MHz keyboards and mice, this has also been tested to not cause
regressions on a non-unifying dual-HID++ nano receiver (046d:c534) with
k270 and m185 HID++-2.0 devices connected and on a unifying/dj receiver
(046d:c52b) with a HID++-2.0 Logitech Rechargeable Touchpad T650.

Signed-off-by: Hans de Goede 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Sasha Levin