Add support for XP-Pen Star G640 to hid-uclogic.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Add support for XP-Pen Star G540 to hid-uclogic.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Add proper support for Ugee EX07(S) frame controls to hid-uclogic.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Add support for Ugee M540 to hid-uclogic.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Add support for Ugee 2150 to hid-uclogic.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Add support for UC-Logic v2 protocol to hid-uclogic.
This adds support for a bunch of new Huion models.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Support parsing fragmented high-resolution reports in hid-uclogic to
support v2 reporting protocol.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Newer UC-Logic tablets, such as ones made by Huion have stopped
reporting in-range state, but they're otherwise worthy tablets. The
manufacturer was notified of the problem and promised to fix this in the
future. Meanwhile, detect pen coming in range, and emulate the reports
to the userspace, to make the tablets useable.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Designate the current UC-Logic tablet initialization protocol v1, in
preparation for adding support for v2 protocol.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Re-initialize UC-Logic tablets on resume. UC-Logic tablet initialization
and parameter retrieval cannot be separated for the large part, so
simply discard the retrieved parameters after initialization.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Refactor and extract UC-Logic tablet initialization and parameter
discovery into a module. For these tablets, the major part of parameter
discovery cannot be separated from initialization so they have to be in
the same module. Define explicitly and clearly what possible quirks the
tablets may have to make the driver implementation easier and simpler.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

As hid-uclogic has a lot of report descriptors already and there's going
to be more, move them out of the driver code and into a separate module.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Add "_UCLOGIC" to Ugee tablet device ID macros so it's clear they come
with UC-Logic vendor ID.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Add support for ViewSonic PD1011 signature (display) pad, which is also
sold by Signotec under a different name.
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Originally contributed by Andrey Alekseenko <al42and@gmail.com>.
Signed-off-by: NAndrey Alekseenko <al42and@gmail.com>
Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Ring buffer implementation in hid_debug_event() and hid_debug_events_read()
is strange allowing lost or corrupted data. After commit 717adfda
("HID: debug: check length before copy_to_user()") it is possible to enter
an infinite loop in hid_debug_events_read() by providing 0 as count, this
locks up a system. Fix this by rewriting the ring buffer implementation
with kfifo and simplify the code.

This fixes CVE-2019-3819.

v2: fix an execution logic and add a comment
v3: use __set_current_state() instead of set_current_state()

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1669187
Cc: stable@vger.kernel.org # v4.18+
Fixes: cd667ce2 ("HID: use debugfs for events/reports dumping")
Fixes: 717adfda ("HID: debug: check length before copy_to_user()")
Signed-off-by: NVladis Dronov <vdronov@redhat.com>
Reviewed-by: NOleg Nesterov <oleg@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Manually tracking an active collection to set collection parents is not
necessary, we just have to look one step back into the collection stack
to find the correct parent.
Signed-off-by: NPhilipp Zabel <philipp.zabel@gmail.com>
Reviewed-by: NPeter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

A Goodix touchpad doesn't work. Touching the touchpad can trigger IRQ
but there's no input event from HID subsystem.

Turns out it reports some invalid data:
[   22.136630] i2c_hid i2c-DELL091F:00: input: 0b 00 01 00 00 00 00 00 00 00 00

After some trial and error, it's another device that doesn't work well
with ON/SLEEP commands. Disable runtime PM to fix the issue.
Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Previously, the pointer to the parent collection was stored. If a device
exceeds 16 collections (HID_DEFAULT_NUM_COLLECTIONS), the array to store
the collections is reallocated, the pointer to the parent collection becomes
invalid.

Replace the pointers with an index-based lookup into the collections array.

Fixes: c53431eb ("HID: core: store the collections as a basic tree")
Reported-by: NPandruvada, Srinivas <srinivas.pandruvada@intel.com>
Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
Tested-by: NKyle Pelton <kyle.d.pelton@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The Odys Winbook 13 uses a SIPODEV SP1064 touchpad, which does not
supply descriptors, add this to the DMI descriptor override list, fixing
the touchpad not working.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1526312Reported-by: NRene Wagner <redhatbugzilla@callerid.de>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In lenovo_probe_tpkbd(), the function of_led_classdev_register() could
return an error value that is unchecked. The fix adds these checks.
Signed-off-by: NAditya Pakki <pakki001@umn.edu>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Now ish hid ipc only support sideband interrupt but on some platforms
they use MSI interrupt.
In order to make the interrupt type coverage all the scenario add
single MSI interrupt support, it can match all interrupt types.
Signed-off-by: NSong Hongyan <hongyan.song@intel.com>
Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: NYangtao Li <tiny.windzz@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The memory chunk allocated by hid_allocate_device() should be released
by hid_destroy_device(), not kfree().

Fixes: 0b28cb4b("HID: intel-ish-hid: ISH HID client driver")
Signed-off-by: NPan Bian <bianpan2016@163.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The ASUS T101HA keyboard dock generates HID events using the ASUS vendor
specific UsagePage 0xff31. In consequence, some multimedia keys such as
brightness up and down are not working with hid-generic.

This commit adds the T101HA dock into the supported device list of the
hid-asus driver. It also prevents the dock's integrated touchpad to be
bound with hid-asus given that it is already working fine with
hid-multitouch.
Signed-off-by: NAleix Roca Nonell <kernelrocks@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Before things go out of hand, make it possible to pass
flags when requesting "own" descriptors from a gpio_chip.
This is necessary if the chip wants to request a GPIO with
active low semantics, for example.

Cc: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Roger Quadros <rogerq@ti.com>
Reviewed-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Signed-off-by: NHarry Cutts <hcutts@chromium.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
Verified-by: NHarry Cutts <hcutts@chromium.org>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

There are three features used by various Logitech mice for
high-resolution scrolling: the scrolling acceleration bit in HID++ 1.0,
and the x2120 and x2121 features in HID++ 2.0 and above. This patch
supports all three, and uses the multiplier reported by the mouse for
the HID++ 2.0+ features.

The full list of product IDs of mice which support high-resolution
scrolling was provided by Logitech, but the patch was tested using the
following mice (using the Unifying receiver):

* HID++ 1.0: Anywhere MX, Performance MX
* x2120: M560
* x2121: MX Anywhere 2, MX Master 2S

This patch is a combinations of the now-reverted commits 1ff2e1a4,
d56ca985, 5fe2ccbe, 044ee890 together with some extra bits for the
directional and timeout-based reset.
The previous patch series was in hid-input, it appears this remainder
handling is logitech-specific and was moved to hid-logitech-hidpp.c and
renamed accordingly.
Signed-off-by: NHarry Cutts <hcutts@chromium.org>
Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
Verified-by: NHarry Cutts <hcutts@chromium.org>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

"Scrolling acceleration" is a bit of a misnomer: it doesn't deal with
acceleration at all. However, that's the name used in Logitech's spec,
so I used it here.
Signed-off-by: NHarry Cutts <hcutts@chromium.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
Verified-by: NHarry Cutts <hcutts@chromium.org>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
Verified-by: NHarry Cutts <hcutts@chromium.org>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Windows uses a magic number of 120 for a wheel click. High-resolution
scroll wheels are supposed to use a fraction of 120 to signal smaller
scroll steps. This is implemented by the Resolution Multiplier in the
device itself.

If the multiplier is present in the report descriptor, set it to the
logical max and then use the resolution multiplier to calculate the
high-resolution events. This is the recommendation by Microsoft, see
http://msdn.microsoft.com/en-us/windows/hardware/gg487477.aspx

Note that all mice encountered so far have a logical min/max of 0/1, so
it's a binary "yes or no" to high-res scrolling anyway.

To make userspace simpler, always enable the REL_WHEEL_HI_RES bit. Where
the device doesn't support high-resolution scrolling, the value for the
high-res data will simply be a multiple of 120 every time. For userspace,
if REL_WHEEL_HI_RES is available that is the one to be used.

Potential side-effect: a device with a Resolution Multiplier applying to
other Input items will have those items set to the logical max as well.
This cannot easily be worked around but it is doubtful such devices exist.
Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
Verified-by: NHarry Cutts <hcutts@chromium.org>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

The Resolution Multiplier is a feature report that modifies the value of
Usages within the same Logical Collection. If the multiplier is set to
anything but 1, the hardware reports (value * multiplier) for the same amount
of physical movement, i.e. the value we receive in the kernel is
pre-multiplied.

The hardware may either send a single (value * multiplier), or by sending
multiplier as many reports with the same value, or a combination of these two
options. For example, when the Microsoft Sculpt Ergonomic mouse Resolution
Multiplier is set to 12, the Wheel sends out 12 for every detent but AC Pan
sends out a value of 3 at 4 times the frequency.

The effective multiplier is based on the physical min/max of the multiplier
field, a logical min/max of [0,1] with a physical min/max of [1,8] means the
multiplier is either 1 or 8.

The Resolution Multiplier was introduced for high-resolution scrolling in
Windows Vista and is commonly used on Microsoft mice.

The recommendation for the Resolution Multiplier is to default to 1 for
backwards compatibility. This patch adds an arbitrary upper limit at 255. The
only known use case for the Resolution Multiplier is for scroll wheels where the
multiplier has to be a fraction of 120 to work with Windows.
Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
Verified-by: NHarry Cutts <hcutts@chromium.org>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

For each collection parsed, store a pointer to the parent collection
(if any). This makes it a lot easier to look up which collection(s)
any given item is part of
Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
Verified-by: NHarry Cutts <hcutts@chromium.org>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

SNES RetroPort and RetroPad register only 4 gamepad buttons
when they should register all 8 buttons. This is described here:

https://ask.fedoraproject.org/en/question/128102

This is happening because of:

Commit 190d7f02 ("HID: input: do not increment usages when
    duplicate is found")

Here, I add the quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE
(created for backward compatibility with the change in 190d7f02)
for the two products.

Tested with both RetroPort and RetroPad.

Cc: stable@vger.kernel.org  # v4.18+
Signed-off-by: NNic Soudée <nsoudee@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

The ASUS FX503VD laptop uses an USB keyboard with several hotkeys
which use the Asus Vendor specific UsagePage.

This uses two usage-codes within the page which have not been seen
before, 0x7c for its mic-mute hotkey and 0x99 for Fn+F5 which has
a "fan" symbol as hotkey symbol on the keyb. we map this to KEY_PROG4
(PROG1-PROG3 are already used).

This commit adds the mappings for the 2 new usage codes and the USB-ids
for this keyboard to the hid-asus driver.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Various Asus devices generate HID events using the Asus Vendor specific
UsagePage 0xff31 and hid-asus will map these in its input_mapping for all
devices to which it binds (independent of any quirks).

Add an event callback which check for unmapped (because sofar unknown)
usages within the Asus Vendor UsagePage and log a warning for these.

The purpose of this patch is to help debugging / find such unmapped codes
and add them to the asus_input_mapping() function.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

The 258a:6a88 keyboard-dock shipped with the Prowise PT301 tablet is
likely another ITE based design. The controller die is directly bonded
to the PCB with a blob of black glue on top so there are no markings and
the 258a vendor-id used is unknown anywhere. But the keyboard has the
exact same hotkeys mapped to Fn+F1 - F10 as the other ITE8595 keyboard
I have *and* it has the same quirky behavior wrt the rfkill hotkey.

Either way as said this keyboard has the same quirk for its rfkill /
airplane mode hotkey as the ITE 8595 chip, it only sends a single release
event when pressed and released, it never sends a press event.

This commit adds the 258a:6a88 USB id to the hid-ite id-table, fixing
the rfkill key not working on this keyboard.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

This reverts commit 1ff2e1a4.

It turns out the current API is not that compatible with
some Microsoft mice, so better start again from scratch.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHarry Cutts <hcutts@chromium.org>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NJiri Kosina <jkosina@suse.cz>

This reverts commit 051dc9b0.

It turns out the current API is not that compatible with
some Microsoft mice, so better start again from scratch.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHarry Cutts <hcutts@chromium.org>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NJiri Kosina <jkosina@suse.cz>

This reverts commit d56ca985.

It turns out the current API is not that compatible with
some Microsoft mice, so better start again from scratch.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHarry Cutts <hcutts@chromium.org>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NJiri Kosina <jkosina@suse.cz>