BMC/Intel-BMC/linux.git/drivers/hid/wacom_sys.c, branch dev-4.3

Merge branches 'for-4.3/chicony', 'for-4.3/cp2112', 'for-4.3/i2c-hid', 'for-4.3/lenovo', 'for-4.3/logitech', 'for-4.3/multitouch', 'for-4.3/picolcd', 'for-4.3/rmi', 'for-4.3/sensor-hub', 'for-4.3/sony' and 'for-4.3/wacom' into for-linus

2015-09-01T13:37:30+00:00

Merge branches 'for-4.2/upstream-fixes-devm-fixed' and 'for-4.3/upstream' into for-linus

2015-09-01T13:23:13+00:00

HID: wacom: Add support for Express Key Remote.

2015-08-28T18:43:20+00:00

This device is pad (buttons) only, there is no stylus or touch. Up to five remotes can pair with the device's associated USB dongle. Signed-off-by: Aaron Skomra Reviewed-by: Jason Gerecke Signed-off-by: Jiri Kosina

HID: wacom: Report correct device resolution when using the wireless adapater

2015-08-10T21:49:56+00:00

The 'wacom_wireless_work' function does not recalculate the tablet's resolution, causing the value contained in the 'features' struct to always be reported to userspace. This value is valid only for the pen interface, meaning that the value will be incorrect for the touchpad (if present). This in particular causes problems for libinput which relies on the reported resolution being correct. This patch adds the necessary calls to recalculate the resolution for each interface. This requires a little bit of code shuffling since both the 'wacom_set_default_phy' and 'wacom_calculate_res' are declared below their new first point of use in 'wacom_wireless_work'. Signed-off-by: Jason Gerecke Signed-off-by: Jiri Kosina

HID: wacom: Do not repeatedly attempt to set device mode on error

2015-08-10T12:23:37+00:00

As an extension of aef3156d7, there is no sense in repeatedly calling the 'wacom_set_report' and 'wacom_get_report' functions if they return an error. Getting an error from them implies that the device is out to lunch: either a hard error code was returned or repeated attempts at recovering from a "soft" error all failed. In either case, doing even more retries is not likely to resolve whatever is wrong. Signed-off-by: Jason Gerecke Signed-off-by: Jiri Kosina

HID: wacom: Do not repeatedly attempt to set device mode on error

2015-08-10T08:47:10+00:00

HID: wacom: Remove WACOM_QUIRK_NO_INPUT

2015-08-04T13:39:21+00:00

WACOM_QUIRK_NO_INPUT is a signal to the driver that input devices should not be created for a particular device. This quirk was used by the wireless receiver to prevent any devices from being created during the initial probe (defering it instead until we got a tablet connection event in 'wacom_wireless_work'). This quirk is not necessary now that a device_type is associated with each device. Any input device allocated by 'wacom_allocate_inputs' which is not necessary for a particular device is freed in 'wacom_register_inputs'. In particular, none of the wireless receivers devices have the pen, pad, or touch device types set so the same effect is achieved without the need to be explicit. We now return early in wacom_retrieve_hid_descriptor for wireless devices (to prevent the device_type from being overridden) but since we ignore the HID descriptor for the wireless reciever anyway, this is not an issue. Signed-off-by: Jason Gerecke Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina

HID: wacom: Replace WACOM_QUIRK_MONITOR with WACOM_DEVICETYPE_WL_MONITOR

2015-08-04T13:39:20+00:00

The monitor interface on the wireless receiver is more logically expressed as a type of device instead of a quirk. Signed-off-by: Jason Gerecke Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina

HID: wacom: Use calculated pkglen for wireless touch interface

2015-08-04T13:39:20+00:00

Commit 01c846f introduced the 'wacom_compute_pktlen' function which automatically determines the correct value for an interface's pkglen by scanning the HID descriptor. This function returns the correct value for the wireless receiver's touch interface, removing the need for us to set it manually here. Signed-off-by: Jason Gerecke Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina

HID: wacom: Perform all event processing as part of report processing

2015-07-23T12:02:43+00:00

In some cases, we need access to information before it becomes available to the 'event' handler. In particular, for some devices we cannot properly process the finger data without first knowing the "contact count" at the very end of the report (e.g. the Cintiq 24HDT touch screen, when forced through the GENERIC codepath). Since the HID subsystem doesn't provide a way to take action before 'event' is called, we take a cue from hid-multitouch.c and add a pre-process step within the 'report' handler that performs the same function. Signed-off-by: Jason Gerecke Signed-off-by: Jiri Kosina