linux-toradex.git/drivers/hid/hid-input.c, branch v4.15

HID: hid-input: Add eraser usage to hidinput_configure_usage

2017-10-05T09:20:12+00:00

Some tablets report eraser usage to indicate the eraser tool tip
is touching the surface. But, hidinput_configure_usage didn't
support the usage, which led it falls into default as ABS_MISC.

Signed-off-by: Ping Cheng 
Signed-off-by: Jiri Kosina

HID: input: throttle battery uevents

2017-08-15T08:56:03+00:00

The power_supply subsystem tends to emit uevent every time
power_supply_changed() is called, so we should call this API only when battery
strength reported by the device is actually different from the previous
readings, otherwise we'll drown the system in uevents.

Fixes: 581c4484769e ("HID: input: map digitizer battery usage")
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jiri Kosina

HID: input: optionally use device id in battery name

2017-08-02T08:51:46+00:00

Manufacturers do not always populate serial number in their devices, so
let's fall back to device ID when forming the battery device name. As a
result, batteries in devices without serial number will be named like
this:

	hid-0018:2D1F:510E.0001-battery

(as opposed to hid--battery for the first one, and failing to create
batteries for the subsequent ones).

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jiri Kosina

HID: input: map digitizer battery usage

2017-08-02T08:51:46+00:00

We already mapped battery strength reports from the generic device
control page, but we did not update capacity from input reports, nor we
mapped the battery strength report from the digitizer page, so let's
implement this now.

Batteries driven by the input reports will now start in "unknown" state,
and will get updated once we receive first report containing battery
strength from the device.

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jiri Kosina

HID: Microsoft Win8 Wireless Radio Controls cleanup

2017-05-22T12:47:43+00:00

Use a better URL for the HUTRR40 Radio HID Usages documentation and use the
HID_GD_WIRELESS_RADIO_CTLS define rather then hardcoding a check for
0x0001000c.

Fixes: 61df56bef9 ("HID: Add mapping for Microsoft Win8 Wireless Radio Controls extensions")
Suggested-by: Benjamin Tissoires 
Signed-off-by: Hans de Goede 
Signed-off-by: Jiri Kosina

HID: Add mapping for Microsoft Win8 Wireless Radio Controls extensions

2017-05-11T08:27:48+00:00

Microsoft has defined some extra HUT codes for the Generic Desktop Page
for Wireless Radio controls, see:

https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/airplane-mode-radio-management
https://web.archive.org/web/20170509144631/https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/airplane-mode-radio-management

I've 3 2-in-1 keyboard docks: Dell Venue Pro 11 keyboard dock,
HP pavilion x2 keyboard dock and a PEAQ C1010 keyboard dock which have
a wireless radio toggle hotkey, which uses the 0x000100c6 HUT code
defined in these extensions.

This commit adds a mapping for this key, this makes the rfkill toggle
hotkey work on the Dell Venue Pro 11 and HP Pavilion X2 keyboards,
the PEAQ C1010 keyboard does generate events for the 0x000100c6 HUT
code when pressed, but the reported value is always 0.

Signed-off-by: Hans de Goede 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: clamp input to logical range if no null state

2017-03-21T13:54:00+00:00

This patch fixes an issue in drivers/hid/hid-input.c where values
outside of the logical range are not clamped when "null state" bit of
the input control is not set.

This was discussed on the lists [1] and this change stems from the fact
due to the ambiguity of the HID specification it might be appropriate to
follow Microsoft's own interpretation of the specification. As noted in
Microsoft's documentation [2] in the section titled "Required HID usages
for digitizers" it is noted that values reported outside the logical
range "will be considered as invalid data and the value will be changed
to the nearest boundary value (logical min/max)."

This patch fixes an issue where the (1292:4745) Innomedia INNEX
GENESIS/ATARI reports out of range values for its X and Y axis of the
DPad which, due to the null state bit being unset, are forwarded to
userspace as is. Now these values will get clamped to the logical range
before being forwarded to userspace. This device was also used to test
this patch.

This patch expands on commit 3f3752705dbd ("HID: reject input outside
logical range only if null state is set").

[1]: http://lkml.kernel.org/r/20170307131036.GA853@gaia.local
[2]: https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85).asp

Signed-off-by: Tomasz Kramkowski 
Acked-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: reject input outside logical range only if null state is set

2017-03-06T13:02:37+00:00

This patch fixes an issue in drivers/hid/hid-input.c where USB HID
control null state flag is not checked upon rejecting inputs outside
logical minimum-maximum range. The check should be made according to USB
HID specification 1.11, section 6.2.2.5, p.31. The fix will resolve
issues with some game controllers, such as:
https://bugzilla.kernel.org/show_bug.cgi?id=68621

[tk@the-tk.com: shortened and fixed spelling in commit message]
Signed-off-by: Valtteri Heikkilä 
Signed-off-by: Tomasz Kramkowski 
Acked-By: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

Merge branches 'for-4.10/asus', 'for-4.10/cp2112', 'for-4.10/i2c-hid-nopower', 'for-4.10/intel-ish', 'for-4.10/mayflash', 'for-4.10/microsoft-surface-3', 'for-4.10/multitouch', 'for-4.10/sony', 'for-4.10/udraw-ps3', 'for-4.10/upstream' and 'for-4.10/wacom/generic' into for-linus

2016-12-14T09:12:26+00:00

HID: input: rework HID_QUIRK_MULTI_INPUT

2016-11-28T13:39:47+00:00

The purpose of HID_QUIRK_MULTI_INPUT is to have an input device per
report id. This is useful when the HID device presents several HID
collections of different device types.

The current implementation of hid-input creates one input node per id per
type (input or output). This is problematic for the LEDs of a keyboard as
they are often set through an output report. The current code creates
one input node with all the keyboard keys, and one other with only the
LEDs.

To solve this, we use a two-passes way:
- first, we initialize all input nodes and associate one per report id
- then, we register all the input nodes

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina