linux-toradex.git/include/linux/hid.h, branch v5.1-rc1

HID: core: simplify active collection tracking

2019-01-16T13:29:48+00:00

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: Philipp Zabel 
Reviewed-by: Peter Hutterer 
Signed-off-by: Benjamin Tissoires

HID: core: replace the collection tree pointers with indices

2019-01-10T06:08:18+00:00

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: c53431eb696f3c ("HID: core: store the collections as a basic tree")
Reported-by: Pandruvada, Srinivas 
Signed-off-by: Peter Hutterer 
Tested-by: Kyle Pelton 
Signed-off-by: Jiri Kosina

Merge branches 'for-4.20/upstream-fixes', 'for-4.21/core', 'for-4.21/hid-asus', 'for-4.21/hid-core', 'for-4.21/hid-cougar', 'for-4.21/hidraw', 'for-4.21/highres-wheel' and 'for-4.21/ish' into for-linus

2019-01-03T11:50:28+00:00

HID: input: use the Resolution Multiplier for high-resolution scrolling

2018-12-07T15:27:13+00:00

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: Peter Hutterer 
Verified-by: Harry Cutts 
Signed-off-by: Benjamin Tissoires

HID: core: process the Resolution Multiplier

2018-12-07T15:27:13+00:00

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: Peter Hutterer 
Verified-by: Harry Cutts 
Signed-off-by: Benjamin Tissoires

HID: core: store the collections as a basic tree

2018-12-07T15:27:12+00:00

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: Peter Hutterer 
Verified-by: Harry Cutts 
Signed-off-by: Benjamin Tissoires

HID: input: support Microsoft wireless radio control hotkey

2018-12-05T14:46:27+00:00

The ASUS laptops start to support the airplane mode radio management
to replace the original mechanism of airplane mode toggle hotkey.
On the ASUS P5440FF, it presents as a HID device connecting via
I2C, named i2c-AMPD0001. When pressing it, the Embedded Controller
send hid report via I2C and switch the airplane mode indicator LED
based on the status.

However, it's not working because it fails to be identified as a
hidinput device. It fails in hidinput_connect() due to the macro
IS_INPUT_APPLICATION doesn't have HID_GD_WIRELESS_RADIO_CTLS as
a legit application code.

It's easy to add the HID I2C vendor and product id to the quirk
list and apply HID_QUIRK_HIDINPUT_FORCE to make it work. But it
makes more sense to support it as a generic input application.

Signed-off-by: Chris Chiu 
Signed-off-by: Benjamin Tissoires

HID: use macros in IS_INPUT_APPLICATION

2018-12-05T14:46:26+00:00

Add missing definition for HID_DG_WHITEBOARD then replace the hid
usage hex with macros for better readibility.

Signed-off-by: Chris Chiu 
Signed-off-by: Benjamin Tissoires

Revert "HID: input: Create a utility class for counting scroll events"

2018-11-22T07:57:38+00:00

This reverts commit 1ff2e1a44e02d4bdbb9be67c7d9acc240a67141f.

It turns out the current API is not that compatible with
some Microsoft mice, so better start again from scratch.

Signed-off-by: Benjamin Tissoires 
Acked-by: Harry Cutts 
Acked-by: Dmitry Torokhov 
Acked-by: Jiri Kosina

HID: fix up .raw_event() documentation

2018-11-06T12:59:08+00:00

The documentation for the .raw_event() callback says that if the
driver return 1, there will be no further processing of the event,
but this is not true, the actual code in hid-core.c looks like this:

  if (hdrv && hdrv->raw_event && hid_match_report(hid, report)) {
           ret = hdrv->raw_event(hid, report, data, size);
           if (ret < 0)
                   goto unlock;
   }

   ret = hid_report_raw_event(hid, type, data, size, interrupt);

The only return value that has any effect on the processing is
a negative error.

Correct this as it seems to confuse people: I found bogus code in
the Razer out-of-tree driver attempting to return 1 here.

Signed-off-by: Linus Walleij 
Signed-off-by: Jiri Kosina