Merge branches 'for-4.0/upstream-fixes', 'for-4.1/genius', 'for-4.1/huion-uclogic-merge', 'for-4.1/i2c-hid', 'for-4.1/kconfig-drop-expert-dependency', 'for-4.1/logitech', 'for-4.1/multitouch', 'for-4.1/rmi', 'for-4.1/sony', 'for-4.1/upstream' and 'for-4.1/wacom' into for-linus

In the unlikely case of hdev vanishing while hid_debug_events_read() was
sleeping, we can't really break out of the case switch as with other cases,
as on the way out we'll try to remove ourselves from the hdev waitqueue.

Fix this by taking a shortcut exit path and avoiding cleanup that doesn't
make sense in case hdev doesn't exist any more anyway.
Reported-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The case occurred recently with a touchscreen using twice a slot during a
single EV_SYN event:

E: 0.288415 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 0.296207 0003 002f 0000      # EV_ABS / ABS_MT_SLOT          0
E: 0.296207 0003 0039 -001      # EV_ABS / ABS_MT_TRACKING_ID   -1
E: 0.296207 0003 002f 0001      # EV_ABS / ABS_MT_SLOT          1
E: 0.296207 0003 0035 0908      # EV_ABS / ABS_MT_POSITION_X    908
E: 0.296207 0003 0036 1062      # EV_ABS / ABS_MT_POSITION_Y    1062
E: 0.296207 0003 002f 0000      # EV_ABS / ABS_MT_SLOT          0
E: 0.296207 0003 0039 8787      # EV_ABS / ABS_MT_TRACKING_ID   8787
E: 0.296207 0003 0035 1566      # EV_ABS / ABS_MT_POSITION_X    1566
E: 0.296207 0003 0036 0861      # EV_ABS / ABS_MT_POSITION_Y    861
E: 0.296207 0003 0000 0908      # EV_ABS / ABS_X                908
E: 0.296207 0003 0001 1062      # EV_ABS / ABS_Y                1062
E: 0.296207 0000 0000 0000      # ------------ SYN_REPORT (0) ----------

This occurred because while having already slots 0 and 1 assigned, the
touchscreen sent:

0.293377 Tip Switch: 0 | Contact Id: 0 | X:  539 | Y: 1960 | Contact Count: 3
0.294783 Tip Switch: 1 | Contact Id: 1 | X:  908 | Y: 1062 | Contact Count: 0
0.296187 Tip Switch: 1 | Contact Id: 2 | X: 1566 | Y:  861 | Contact Count: 0

Slot 0 is released correclty, but when we look for Contact ID 2, the slot
0 is then picked up again because it is marked as inactive (trackingID < 0).

This is wrong, and we should not reuse a slot in the same frame.
The test should also check for input_mt_is_used().

In addition, we need to initialize mt->frame to an other value than 0.
With mt->frame being 0, all slots are tags as currently used, and so
input_mt_get_slot_by_key() would return -1 for all requests.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=88903Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Return a negative error code on failure.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Cintiq 13HD Touch is a new display tablet with pen and 10 finger touches.
Signed-off-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The Logitech T650 used to report 3 fingers swipes to the up as a press on the
Super key. When we switched the touchpad to the raw mode, we also disable such
firmware gesture and some users may rely on it.

Unfortunately, 3 finger swipes are still not supported in most of the Linux
environments, which means that we disabled a feature of the touchpad.

Allow users to revert the raw reporting mode and keep going with the firmware
gestures by providing a new module parameter.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The device exists with two device IDs instead of one as previously
believed.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

During a stress test these mice kept dropping and reappearing
in runlevel 1 as opposed to 5.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In wacom_bpt_pen, we checked touch_down before assigning new
stylus_in_proximity value. This would cause stylus_in_proximity not updated
properly if touch is down before pen is in proximity.

[jkosina@suse.cz: fix if-else style]
Signed-off-by: NPing Cheng <pingc@wacom.com>
Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Counting number of touching fingers by wacom_wac_finger_count_touches so we
don't have to count them inside individual routines.
Signed-off-by: NPing Cheng <pingc@wacom.com>
Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The quirk was added for devices that support both pen and touch.  It decides if
a device supports multiple inputs by hardcoded feature type. However, for some
devices, we do not know if they support both before accessing their HID
descriptors.

This patch relies on dynamically assigned device_type to make the decision.
Also, we make it certain that wacom_wac->shared is always created. That is, the
driver will not be loaded if it fails to create wacom_wac->shared.
Signed-off-by: NPing Cheng <pingc@wacom.com>
Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Conflicts:
	drivers/hid/wacom_wac.c

Need to fetch the 4.0 fixes to apply 4.1 patches based on top
of those.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Force-beedback core guarantees that the 'effect' pointer that's being passed
to ->upload() callback is non-NULL.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This mouse is also known under other IDs. It needs the quirk or will disconnect
in runlevel 1 or 3.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
CC: stable@vger.kernel.org
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This mouse needs QUIRK_ALWAYS_POLL.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
CC: stable@vger.kernel.org
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

486b908d (HID: wacom: do not send pen events before touch is up/forced out)
introduces a kernel oops when plugging a tablet without touch.

wacom->shared is null for these devices so this leads to a null pointer
exception.

Change the condition to make it clear that what we need is wacom->shared
not NULL.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

If noone listens to the input device when a tool comes in proximity,
the tablet does not send the in-prox event when a client becomes available.
That means that no events will be sent until the tool is taken out of
proximity.

In this situation, ask for the report WACOM_REPORT_INTUOSREAD which will
read the corresponding feature and generate an in-prox event.
To make some generation of hardware working, we need to unset the
quirk NO_GET set by hid-core because the interfaces are seen as "boot
mouse".

We don't schedule this read in a worker while we are in an IO interrupt.
We know that usbhid will do it asynchronously. If this is triggered by
uhid, then this is obviously a client side bug :)
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This driver didn't exist until before v3.19.
Why would suddenly everybody want to build it?
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The PID driver (usbhid/hid-pidff.c) does not set the effect ID when
uploading an effect. The result is that the initial upload works but
subsequent uploads to modify effect parameters are all directed at the
last-created effect.

The targeted effect ID must be passed back to the device when effect
parameters are changed. This is done at the start of
"pidff_set_condition_report", "pidff_set_periodic_report" etc. based on
the value of "pidff->block_load[PID_EFFECT_
BLOCK_INDEX].value[0]".

This value is only ever set during pidff_request_effect_upload.
The result is stored in "pidff->pid_id[effect->id]" at the end of
pid_upload_effect, for later use. However, if an effect is modified and
re-sent then this identifier is not being copied back from
pidff->pid_id[effect->id] before sending the command to the device. The
fix is to do this at the start of pidff_upload_effect.
Signed-off-by: NJim Keir <jimkeir@oracledbadirect.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Many HID driver options are hidden unless EXPERT is set. While I
understand the idea of simplifying the kernel configuration for most
users, in practice I believe it adds more confusion than it helps.

One thing that worries me is that, in non-EXPERT mode, these drivers
will be either built-in or modular based on apparent magic. For
example, switching INPUT and HID from m to y will cause all these
drivers to be built into the kernel when they were previously built
as modules. Short of enabling EXPERT mode altogether, the user has no
control over that.

Generally I do not think tristate options should depend on !EXPERT.
Of these, 11 of 15 are currently in the hid subsystem.

The HID_LOGITECH option is even worse than the others. Sub-options
depend on it, and this causes menuconfig and friends to display the
option even though the user can't change its value. The help page for
HID_LOGITECH will not explain why the value can't be changed. It only
says, for example:

  Depends on: INPUT [=y] && HID [=y]

and that leaves the user puzzled about why the option is forced to y.
You might argue that this is a Kconfig bug, but that doesn't make it
less annoying for the user.

Even worse is that some of the sub-options of HID_LOGITECH select
INPUT_FF_MEMLESS, which in turn gets out of control for the user. So,
if you set INPUT=y and HID=y (something most general purpose
distributions would do these days, as both modules would get loaded on
a vast majority of systems otherwise), and you want support for
force-feedback game controllers, you can't have that as a module, it
has to be built-in, regardless of how rare these devices are.

Of course, all this madness goes away once EXPERT is enabled, but then
the rest of the kernel configuration becomes more complex, which
totally voids the original point.

For this reason, I would like all HID device tristate options to be
displayed regardless of EXPERT being set or not. We can let the
default settings still depend on EXPERT, that's not intrusive.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

No need to retrieve the USB handle in input_mapping() when we already
do that in probe. It also allows to use the quirk without having to
add the product ID matching.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Makefile that can actually build the example, and allow selecting device to
work on.
Signed-off-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The linux kernel has supported the TiVo Slide remote control for some time, but
does not recognize the USB ID of the newer Slide Pro. This patch adds the
missing data structures so the newer remote will be recognized by the driver,
thereby allowing the TiVo, LiveTV, and Thumbs Up/Down buttons to be
mapped with a hwdb file.
Signed-off-by: NForest Wilkinson <web11.forest@tibit.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

According to [1], Windows Precision Touchpad devices must supply
a button type usage in the device capabilities feature report. A
value of 0 indicates that the device contains a depressible
button (i.e. it's a click-pad) whereas a value of 1 indicates
a non-depressible button. Add support for this usage and set
INPUT_PROP_BUTTONPAD on the touchpad input device whenever a
depressible button is present.

[1] https://msdn.microsoft.com/en-us/library/windows/hardware/dn467314(v=vs.85).aspxSigned-off-by: NSeth Forshee <seth.forshee@canonical.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Declare the POWER_SUPPLY_PROP_PRESENT property to provide userspace
with a way to determine if the battery on a wireless tablet is plugged
in. Although current wireless tablets do not explicitly report this
information, it can be inferred from other state information. In
particular, a battery is assumed to be present if any of the following
are true: a non-zero battery level reported, the battery is reported as
charging, or the tablet is operating wirelessly.

Note: The last condition above may not strictly hold for the Graphire
Wireless (it charges from a DC barrel jack instead of a USB port), but I
do not know what is reported in the no-battery condition.
Signed-off-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This device disconnects every 60s without X
Signed-off-by: NOliver Neukum <oliver@neukum.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The constant is not used (leftover from previous patch versions
that never got merged).
Reported-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The status packet for tablets which can use a wireless module contains a
bit that is set if the battery is charging. This bit will be 0 if either
a battery is not present or if the battery has reached full charge. Note
that the charging circuit may continue to charge the battery for a short
time after reaching "100%".
Signed-off-by: NJason Gerecke <killertofu@gmail.com>
Acked-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Calls the wacom_status_irq function to report battery status for the
Intuos Pro and Intuos5 (in addition to the already-reporting Intuos
and last-generation Bamboo).
Signed-off-by: NJason Gerecke <killertofu@gmail.com>
Acked-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

If a wireless adapter (which contains the charging circuitry) is
detected as being attached to the tablet then create a new battery
interface and update its status as data is reported. Also destroy the
battery if the adapter goes away.
Signed-off-by: NJason Gerecke <killertofu@gmail.com>
Acked-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Tablets like the Intuos, Intuos Pro, and Bamboo have a connector for an
optional wireless module that can be connected on the fly. The presence
(or absence) of this module is indicated in a status report recieved
from the tablet. This patch adds a workqueue function that will create
or destroy a power_supply object at runtime to match the current state
of the WACOM_QUIRK_BATTERY flag.
Signed-off-by: NJason Gerecke <killertofu@gmail.com>
Acked-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Has the 'wacom_notify_battery' function take on the job of detecting if
updating the power supply is necessary to remove multiple
nearly-identical 'if' blocks.
Signed-off-by: NJason Gerecke <killertofu@gmail.com>
Acked-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In addition to the touchswitch state for "Intuos", these packets are
also sent by the Intuos Pro, Intuos5, and last-generation Bamboo
tablets when using a wired connection. They contain, among other
things, information about the optional wireless module and battery
charge state (to be supported in subsuquent patches).
Signed-off-by: NJason Gerecke <killertofu@gmail.com>
Acked-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Touchpads that have only one button are called clickpads and should
be advertised as such by the kernel.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NJason Ekstrand <jason@jlekstrand.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Currently HID code maps usages from telephony page into BTN_0, BTN_1, etc
keys which get interpreted by mousedev and userspace as left/right/middle
button clicks, which is not really helpful.

This change adds mappings for usages that have corresponding input event
definitions, and leaves the rest unmapped. This can be changed when
there are userspace consumers for more telephony usages.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In commit 08177f40 (HID: uclogic: merge hid-huion driver in hid-uclogic)
HID_HUION depends explicitely on USB_HID because it contained quite some
USB-isms.

Now that hid-uclogic is the new home of Huion tablets, we need to also
add the dependency on USB_HID to this driver.
Reported-by: NJiri Kosina <jkosina@suse.cz>
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This hack is only needed for Huion tablets. It does not seem to have
any effect on the other tablets handled by this device right now, but
it's better to check for the product id sooner than discovering that
we have messed up one tablet later.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Some Huion tablets present 2 HID Pen interfaces. Only one is used, so
we can drop the unused one.
Reviewed-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

NO_EMPTY_INPUT is useful when MULTI_INPUT is set. It prevents to create
empty input nodes that user space does not know what to do with.

It does not seem to be required at the moment, this is just a preventive
patch. This check is only made during the plug of the device, so it does
not hurt to have it.
Reviewed-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

We append "Pen", "Pad", "Mouse", "Keyboard", "Consumer Control" or
"System Control" suffix to the appropriate input node to match what
the Wacom driver does and be more convenient for the user to know
which one is which.
Reviewed-by: NNikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>