linux-stable.git/drivers/hid/hid-input.c, branch linux-3.13.y

HID: Fix unit exponent parsing again

2013-10-18T13:13:39+00:00

Revert some changes done in 774638386826621c984ab6994439f474709cac5e.

Revert all changes done in hidinput_calc_abs_res as it mistakingly used
"Unit" item exponent nibbles to affect resolution value. This wasn't
breaking resolution calculation of relevant axes of any existing
devices, though, as they have only one dimension to their units and thus
1 in the corresponding nible.

Revert to reading "Unit Exponent" item value as a signed integer in
hid_parser_global to fix reading specification-complying values. This
fixes resolution calculation of devices complying to the HID standard,
including Huion, KYE, Waltop and UC-Logic graphics tablets which have
their report descriptors fixed by the drivers.

Explanations follow.

There are two "unit exponents" in HID specification and it is important
not to mix them. One is the global "Unit Exponent" item and another is
nibble values in the global "Unit" item. See 6.2.2.7 Global Items.

The "Unit Exponent" value is just a signed integer and is used to scale
the integer resolution unit values, so fractions can be expressed.

The nibbles of "Unit" value are used to select the unit system (nibble
0), and presence of a particular basic unit type in the unit formula and
its *exponent* (or power, nibbles 1-6). And yes, the latter is in two
complement and zero means absence of the unit type.

Taking the representation example of (integer) joules from the
specification:

[mass(grams)][length(centimeters)^2][time(seconds)^-2] * 10^-7

the "Unit Exponent" would be -7 (or 0xF9, if stored as a byte) and the
"Unit" value would be 0xE121, signifying:

Nibble  Part        Value   Meaning
-----   ----        -----   -------
0       System      1       SI Linear
1       Length      2       Centimeters^2
2       Mass        1       Grams
3       Time        -2      Seconds^-2

To give the resolution in e.g. hundredth of joules the "Unit Exponent"
item value should have been -9.

See also the examples of "Unit" values for some common units in the same
chapter.

However, there is a common misunderstanding about the "Unit Exponent"
value encoding, where it is assumed to be stored the same as nibbles in
"Unit" item. This is most likely due to the specification being a bit
vague and overloading the term "unit exponent". This also was and still
is proliferated by the official "HID Descriptor Tool", which makes this
mistake and stores "Unit Exponent" as such. This format is also
mentioned in books such as "USB Complete" and in Microsoft's hardware
design guides.

As a result many devices currently on the market use this encoding and
so the driver should support them.

Signed-off-by: Nikolai Kondrashov 
Acked-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: validate feature and input report details

2013-09-13T13:13:22+00:00

When dealing with usage_index, be sure to properly use unsigned instead of
int to avoid overflows.

When working on report fields, always validate that their report_counts are
in bounds.
Without this, a HID device could report a malicious feature report that
could trick the driver into a heap overflow:

[  634.885003] usb 1-1: New USB device found, idVendor=0596, idProduct=0500
...
[  676.469629] BUG kmalloc-192 (Tainted: G        W   ): Redzone overwritten

CVE-2013-2897

Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires 
Acked-by: Kees Cook 
Signed-off-by: Jiri Kosina

Merge branches 'for-3.12/devm', 'for-3.12/i2c-hid', 'for-3.12/i2c-hid-dt', 'for-3.12/logitech', 'for-3.12/multitouch-win8', 'for-3.12/trasnport-driver-cleanup', 'for-3.12/uhid', 'for-3.12/upstream' and 'for-3.12/wiimote' into for-linus

2013-09-06T09:58:37+00:00

HID: battery: don't do DMA from stack

2013-09-02T11:43:00+00:00

Instead of using data from stack for DMA in hidinput_get_battery_property(),
allocate the buffer dynamically.

Cc: stable@kernel.org
Reported-by: Richard Ryniker 
Reported-by: Alan Stern 
Signed-off-by: Jiri Kosina

HID: input: generic hidinput_input_event handler

2013-07-31T09:02:02+00:00

The hidinput_input_event() callback converts input events written from
userspace into HID reports and sends them to the device. We currently
implement this in every HID transport driver, even though most of them do
the same.

This provides a generic hidinput_input_event() implementation which is
mostly copied from usbhid. It uses a delayed worker to allow multiple LED
events to be collected into a single output event.
We use the custom ->request() transport driver callback to allow drivers
to adjust the outgoing report and handle the request asynchronously. If no
custom ->request() callback is available, we fall back to the generic raw
output report handler (which is synchronous).

Drivers can still provide custom hidinput_input_event() handlers (see
logitech-dj) if the generic implementation doesn't fit their needs.

Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina

Merge branches 'for-3.11/multitouch', 'for-3.11/sony' and 'for-3.11/upstream' into for-linus

2013-07-04T13:02:26+00:00

Conflicts:
	drivers/hid/hid-core.c

HID: explain out-of-range check better

2013-06-19T21:54:10+00:00

Extend the comment explaining the condition for discarding
out-of-range values to clarify the cases in which devices don't
provide any logical min/max.

Signed-off-by: Jiri Kosina

HID: fix false positive out of range values

2013-06-19T21:53:52+00:00

Commit 6da7066906e977d42104a859c490f5f9a300488c introduced in 3.3
"HID: ignore absolute values which don't fit between logical min and max"
prevents some Posiflex touch screen to work because they do not provide
logical min and max for their buttons.
Thus, logical min and max are at 0, discarding the buttons events, and
preventing the device to report appropriate X Y.

Adding a check on "min < max" solves the problem.

Reported-by: Jan Kandziora 
Tested-by: Jan Kandziora 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: input: return ENODATA if reading battery attrs fails

2013-05-29T13:19:47+00:00

power_supply core has the bad habit of calling our battery callbacks
from within power_supply_register(). Furthermore, if the callbacks
fail with an unhandled error code, it will skip any uevent that it
might currently process.
So if HID-core registers battery devices, an "add" uevent is generated
and the battery callbacks are called. These will gracefully fail due
to timeouts as they might still hold locks on event processing. One
could argue that this should be fixed in power_supply core, but the
least we can do is to signal ENODATA so power_supply core will just
skip the property and continue with the uevent.

This fixes a bug where "add" and "remove" uevents are skipped for
battery devices. upower is unable to track these devices and currently
needs to ignore them.

This patch also overwrites any other error code. I cannot see any reason
why we should forward protocol- or I/O-errors to the power_supply core.
We handle these errors in hid_ll_driver later, anyway, so just skip
them. power_supply core cannot do anything useful with them, anyway,
and we avoid skipping important uevents and confusing user-space.

Thanks a lot to Daniel Nicoletti for pushing and investigating
on this.

Cc: Jiri Kosina 
Cc: Anton Vorontsov 
Cc: David Woodhouse 
Reported-by: Daniel Nicoletti 
Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina

HID: input: don't register unmapped input devices

2013-03-27T13:02:45+00:00

There is no need to register an input device containing no events.
This allows drivers using the quirk MULTI_INPUT to register one input
per report effectively used.

For backward compatibility, we need to add a quirk to request
this behavior.

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