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

Merge branch 'for-4.18/multitouch' into for-linus

2018-06-08T08:25:50+00:00

- improvement of duplicate usage handling in hid-input from Benjamin Tissoires
- Win 8.1 precisioun touchpad spec implementation from Benjamin Tissoires

HID: input: append a suffix matching the application

2018-04-26T12:17:31+00:00

Given that we create one input node per application, we should name
the input node accordingly to not lose userspace.

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

HID: generic: create one input report per application type

2018-04-26T12:17:31+00:00

It is not a good idea to try to fit all types of applications in the
same input report. There are a lot of devices that are needing
the quirk HID_MULTI_INPUT but this quirk doesn't match the actual HID
description as it is based on the report ID.

Given that most devices with MULTI_INPUT I can think of split nicely
the devices inputs into application, it is a good thing to split the
devices by default based on this assumption.

Also make hid-multitouch following this rule, to not have to deal
with too many input created.

While we are at it, fix some checkpatch complaints about converting
'unsigned' to 'unsigned int'.

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

HID: store the full list of reports in the hidinput

2018-04-26T12:17:31+00:00

We were only storing the report in case of QUIRK_MULTI_INPUT.
It is interesting for the upcoming  HID_QUIRK_INPUT_PER_APP to also
store the full list of reports that are attached to it.

We need the full list because a device (Advanced Silicon has some)
might want to use a different report ID for the Input reports and
the Output reports. Storing the full list allows the drivers to
have all the data.

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

HID: input: do not increment usages when a duplicate is found

2018-04-17T12:08:54+00:00

This is something that bothered us from a long time. When hid-input
doesn't know how to map a usage, it uses *_MISC. But there is something
else which increments the usage if the evdev code is already used.

This leads to few issues:
- some devices may have their ABS_X mapped to ABS_Y if they export a bad
  set of usages (see the DragonRise joysticks IIRC -> fixed in a specific
  HID driver)
- *_MISC + N might (will) conflict with other defined axes (my Logitech
  H800 exports some multitouch axes because of that)
- this prevents to freely add some new evdev usages, because "hey, my
  headset will now report ABS_COFFEE, and it's not coffee capable".

So let's try to kill this nonsense, and hope we won't break too many
devices.

I my headset case, the ABS_MISC axes are created because of some
proprietary usages, so we might not break that many devices.

For backward compatibility, a quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE
is created and can be applied to any device that needs this behavior.

Signed-off-by: Benjamin Tissoires 
Acked-by: Peter Hutterer 
Acked-by: Dmitry Torokhov 
Signed-off-by: Jiri Kosina

HID: input: fix battery level reporting on BT mice

2018-04-09T07:26:12+00:00

The commit 581c4484769e ("HID: input: map digitizer battery usage")
assumed that devices having input (qas opposed to feature) report for
battery strength would report the data on their own, without the need to
be polled by the kernel; unfortunately it is not so. Many wireless mice
do not send unsolicited reports with battery strength data and have to
be polled explicitly. As a complication, stylus devices on digitizers
are not normally connected to the base and thus can not be polled - the
base can only determine battery strength in the stylus when it is in
proximity.

To solve this issue, we add a special flag that tells the kernel
to avoid polling the device (and expect unsolicited reports) and set it
when report field with physical usage of digitizer stylus (HID_DG_STYLUS).
Unless this flag is set, and we have not seen the unsolicited reports,
the kernel will attempt to poll the device when userspace attempts to
read "capacity" and "state" attributes of power_supply object
corresponding to the devices battery.

Fixes: 581c4484769e ("HID: input: map digitizer battery usage")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198095
Cc: stable@vger.kernel.org
Reported-and-tested-by: Martin van Es 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jiri Kosina

Merge branch 'for-4.17/multitouch' into for-linus

2018-04-05T11:27:22+00:00

Pull Razer Blade Stealth support improvement and a few generic cleanups

HID: core: remove the need for HID_QUIRK_NO_EMPTY_INPUT

2018-03-23T14:44:57+00:00

There is no real point of registering an empty input node.
This should be default, but given some drivers need the blank input
node to set it up during input_configured, we need to postpone
the check for hidinput_has_been_populated().

Signed-off-by: Benjamin Tissoires 
Acked-by: Peter Hutterer 
Signed-off-by: Jiri Kosina

HID: Fix hid_report_len usage

2018-02-16T12:30:56+00:00

Follow the change of return type u32 of hid_report_len,
fix all the types of variables those get the return value of
hid_report_len to u32, and all other code already uses u32.

Cc: stable@vger.kernel.org
Signed-off-by: Aaron Ma 
Signed-off-by: Jiri Kosina

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