Commit Graph

23 Commits

Author SHA1 Message Date
Jiri Kosina
988b7fb0bf Merge branches 'for-3.19/upstream-fixes', 'for-3.20/apple', 'for-3.20/betop', 'for-3.20/lenovo', 'for-3.20/logitech', 'for-3.20/rmi', 'for-3.20/upstream' and 'for-3.20/wacom' into for-linus 2015-02-09 11:17:45 +01:00
Benjamin Tissoires
005b3f574a HID: logitech-hidpp: store the name of the device in struct hidpp
If a disconnect occurs while getting the actual name of the device
(which can take several HID transactions), the name of the device will
be the hid name, provided by the Unifying Receiver.
This means that in some cases, the user space will see a different
name that what it usually sees when there is no disconnect.

We should store the name of the device in the struct hidpp. That way,
if a disconnect occurs while we are accessing the name,
hidpp_connect_event() can fail, and the input node is not created.

The input node will be created only if we have a connection which
lasts long enough to retrieve all the requested information:
name, protocol, and specific configuration.

Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-01-09 11:29:39 +01:00
Benjamin Tissoires
a0e625f8b7 HID: logitech-hidpp: prefix the name with "Logitech"
Current names are reported as "K750", "M705", and it can be misleading
for the users when they look at their input device list.

Prefixing the names with "Logitech " makes things better.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-12-19 11:53:05 +01:00
Peter Wu
8abd820503 HID: logitech-hidpp: avoid unintended fall-through
Add a return to avoid a fall-through. Introduced in commit
57ac86cf52 ("HID: logitech-hidpp: add
support of the first Logitech Wireless Touchpad").

Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-12-19 11:45:36 +01:00
Peter Wu
f677bb150c HID: logitech-hidpp: detect HID++ 2.0 errors too
Devices speaking HID++ 2.0 report a different error code (0xff). Detect
these errors too to avoid 5 second delays when the device reports an
error. Caught by... well, a bug in the QEMU emulation of this receiver.

Renamed fap to rap for HID++ 1.0 errors because it is more logical,
it has no functional difference.

Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-12-19 11:44:11 +01:00
Benjamin Tissoires
b1ac9487c8 HID: logitech-hidpp: prefix the name with "Logitech"
Current names are reported as "K750", "M705", and it can be misleading
for the users when they look at their input device list.

Prefixing the names with "Logitech " makes things better.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-12-17 10:34:06 +01:00
Benjamin Tissoires
bf15944753 HID: logitech-hidpp: bail out if wtp_connect fails
If wtp_connect() fails, that means most of the time that the device has
been disconnected. Subsequent attempts to contact the device will fail
too, so it's simpler to bail out earlier.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-12-17 09:08:26 +01:00
Peter Wu
e529fea919 HID: logitech-hidpp: separate HID++ from WTP processing
Previously wtp_raw_event would be called through
hidpp_raw_hidpp_event (for the touchpad report) and hidpp_raw_event
(for the mouse report).

This patch removes one calling surface, making a clearer distinction
between "generic HID++ processing" (matching internal reports) and
device-specific event processing.

Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-12-17 08:53:51 +01:00
Peter Wu
0b3f6569a5 HID: logitech-hidpp: check WTP report length
Malicious USB devices can send bogus reports smaller than the expected
buffer size. Ensure that the length for WTP reports is valid to avoid
reading out of bounds.

Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-12-17 08:51:52 +01:00
Peter Wu
f486d9dbcc HID: logitech-hidpp: disable io in probe error path
Balance a hid_device_io_start() call with hid_device_io_stop() in the
error path. This avoids processing of HID reports when the probe fails
which possibly leads to invalid memory access in hid_device_probe() as
report_enum->report_id_hash might already be freed via
hid_close_report().

hid_set_drvdata() is called before wtp_allocate, be consistent and clear
drvdata too on the error path of wtp_allocate.

Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-12-11 23:10:01 +01:00
Peter Wu
3a034a7a7d HID: logitech-hidpp: add boundary check for name retrieval
The HID response has a limited size. Do not trust the value returned by
hardware, check that it really fits in the message.

Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-12-11 23:10:00 +01:00
Peter Wu
1430ee73b5 HID: logitech-hidpp: check name retrieval return code
hidpp_devicenametype_get_device_name() may return a negative value on
protocol errors (for example, when the device is powered off).
Explicitly check this condition to avoid a long-running loop.

(0 cannot be returned as __name_length - index > 0, but check for it
anyway as it would otherwise result in an infinite loop.)

Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-12-11 23:10:00 +01:00
Peter Wu
02cc097e62 HID: logitech-hidpp: do not return the name length
We do not make any use of the actual name length get through
hidpp_get_device_name(). Original patch by Benjamin Tissoires, this
patch also replaces a (now) unnecessary goto by return NULL.

Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-12-11 23:10:00 +01:00
Benjamin Tissoires
552f12eb68 HID: logitech-hidpp: 2 fixes in hidpp_root_get_protocol_version()
- remove the constant '1'
- when the device is not connected, the protocol error
  HIDPP_ERROR_RESOURCE_ERROR is raised. We should not warn the user about
  it because it is somewhat expected as an answer when we check if the
  device is connected.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-11-04 11:10:19 +01:00
Benjamin Tissoires
8c9952b26b HID: logitech-hidpp: fix negated returns
Reported by Dan Carpenter:

drivers/hid/hid-logitech-hidpp.c:359 hidpp_root_get_protocol_version() warn: should this return really be negated?
drivers/hid/hid-logitech-hidpp.c:398 hidpp_devicenametype_get_count() warn: should this return really be negated?
drivers/hid/hid-logitech-hidpp.c:417 hidpp_devicenametype_get_device_name() warn: should this return really be negated?
drivers/hid/hid-logitech-hidpp.c:524 hidpp_touchpad_get_raw_info() warn: should this return really be negated?

The problem lies in hidpp_send_message_sync() which can return 2 types of
errors depending of their sign. Adding a comment there to clarify what is
happening.

To solve that, print an error in case of a protocol problem, and raise
-EPROTO instead.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-11-04 11:10:19 +01:00
Dan Carpenter
3e7830ceb9 HID: logitech-hidpp: leaks and NULL dereferences
Shift the allocation down a few lines to avoid a memory leak and also
add a check for allocation failure.

Fixes: 2f31c52529 ('HID: Introduce hidpp, a module to handle Logitech hid++ devices')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-11-03 14:26:50 +01:00
Benjamin Tissoires
3a61e97563 HID: logitech-hidpp: support combo keyboard touchpad TK820
The TK820 presents both a keyboard and a touchpad on the same
physical (and logical device). Use the generic hid-input
processing for the keyboard part. The keyboard input device is created
when the receiver is plugged in, so no events are missed on connect.

When the device actaully connects, we can set it to use the raw
multitouch reporting to have a consistent user experience accross
all Logitech touchpads.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-10-29 10:51:42 +01:00
Benjamin Tissoires
57ac86cf52 HID: logitech-hidpp: add support of the first Logitech Wireless Touchpad
This touchpad differs from the T650 in several ways:
- the resolution is not correctly returned by the device
- it presents physical buttons, so the button flag in the raw touch report
  is not filled.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-10-29 10:51:41 +01:00
Benjamin Tissoires
586bdc4e4f HID: logitech-hidpp: Add Wireless Touchpad T650 support
All the bits are now in place to add the support of the
Touchpad T650.
The creation/population of the input device is delayed until
the device is ready.

The T650 uses the special HID++ reporting protocol, so activate
this on connect.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-10-29 10:51:41 +01:00
Benjamin Tissoires
c39e3d5fc9 HID: logitech-hidpp: late bind the input device on wireless connection
Now that the receiver forwards the connect/disconnect events, we can
know when the device is available to communicate with us.

When it is ready, we can for instance retrieve its full name, which
guarantee that we always have the same name for the DJ device (the DJ
name is somewhat shorter than the HID++ name).

This mechanism is mandatory for the touchpads line, which has the
min/max information stored in the device. This information can only
be retrieved when the device is connected. So we can not populate
the input device until we are sure that the device is connected.

This patch creates a new input device for such devices. However,
this input is not bound to hid directly, so the various drivers
which wants to use it are required to process completely the
incoming reports in .raw_event().

Note that the patch in itself just adds the bits for the next
ones, and this feature is disabled by default.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-10-29 10:51:41 +01:00
Benjamin Tissoires
33797820af HID: logitech: allow the DJ device to request the unifying name
The names of the DJ devices are stored in the receiver. These names
can be retrieved through a HID++ command. However, the protocol says
that you have to ask the receiver for that, not the device iteself.

Introduce a special case in the DJ handling where a device can request
its unifying name, and when such a name is given, forward it also to
the corresponding device.

On the HID++ side, the receiver talks only HID++ 1.0, so we need to
implement this part of the protocol in the module.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-10-29 10:51:40 +01:00
Benjamin Tissoires
ab94e562ed HID: logitech: move dj devices to the HID++ module
Devices connected through the Logitech Wireless Receiver are HID++ devices.
We can handle them here to benefit from this new module and activate
enhaced support of the various wireless touchpad or mice with touch
sensors on them.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-10-29 10:51:39 +01:00
Benjamin Tissoires
2f31c52529 HID: Introduce hidpp, a module to handle Logitech hid++ devices
Logitech devices use a vendor protocol to communicate various
information with the device. This protocol is called HID++,
and an exerpt can be found here:
https://drive.google.com/folderview?id=0BxbRzx7vEV7eWmgwazJ3NUFfQ28&usp=shar

The main difficulty which is related to this protocol is that
it is a synchronous protocol using the input reports.
So when we want to get some information from the device, we need
to wait for a matching input report.

This driver introduce this capabilities to be able to support
the multitouch mode of the Logitech Wireless Touchpad T651
(the bluetooth one). The multitouch data is available directly
from the mouse input reports, and we just need to query the device
on connect about its caracteristics.

HID++ and the touchpad features has a specific reporting mode
which uses pure HID++ reports, but Logitech told us not to use
it for this specific device. During QA, they detected that
some bluetooth input reports where lost, and so the only supported
mode is the pointer mode.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-10-29 10:51:39 +01:00