The Intuos Pro seems to not like when we set the features right after
being powered up. Instead of waiting during probe, we can schedule the
switch mode and LED control in a deferred worker so that we don't have the
5 secs of delay from USB when the device is not accessible.

The USB timeout delays were really a pain because if you happen to unplug
the tablet while it is still waiting, you are just adding 5 second timeouts
to the USB stack. Which means that a new plug of the same tablet will also
gets delayed, and will also attempt to access the hardware while in
.probe(). So the tablet doesn't appear in the dmesg, the user unplug/replug
it to make it appearing... and so on so forth.

Really, this is for the best :)
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When the LED class gets removed, it actually tries to reset the LED.
However, the device being disconnected, the set_report fails.

Previously, the attempt to cut lose this last event was through unsetting
the HID drvdata, but it was not working properly. Simply reset the LED
groups to NULL makes a more efficient solution.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In the general case, the resources are properly released by devm without
needing to do anything. However, when unplugging the wireless receiver,
the kernel segfaults from time to time while calling devres_release_all().

I think in that case the resources attempt to access hid_get_drvdata(hdev)
which has been set to null while leaving wacom_remove().
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Commit 345857bb ("HID: wacom: generic: Add support for sensor offsets") included
a change to the operation and location of the call to 'wacom_add_shared_data'
in 'wacom_parse_and_register'. The modifications included moving it higher up
so that it would occur before the call to 'wacom_retrieve_hid_descriptor'. This
was done to prevent a crash that would have occured when the report containing
tablet offsets was fed into the driver with 'wacom_hid_report_raw_event'
(specifically: the various 'wacom_wac_*_report' functions were written with the
assumption that they would only be called once tablet setup had completed;
'wacom_wac_pen_report' in particular dereferences 'shared' which wasn't yet
allocated).

Moving the call to 'wacom_add_shared_data' effectively prevented the crash but
also broke the sibiling detection code which assumes that the HID descriptor
has been read and the various device_type flags set.

To fix this situation, we restore the original 'wacom_add_shared_data'
operation and location and instead implement an alternative change that can
also prevent the crash. Specifically, we notice that the report functions
mentioned above expect to be called only for input reports.  By adding a check,
we can prevent feature reports (such as the offset report) from
causing trouble.

Fixes: 345857bb ("HID: wacom: generic: Add support for sensor offsets")
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Tested-by: NPing Cheng <pingc@wacom.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Make sure to check for short control transfers in order to avoid parsing
uninitialised buffer data and leaking it to user space.

Note that the backlight and macro-mode buffer constraints are kept as
loose as possible in order to avoid any regressions should the current
buffer sizes be larger than necessary.

Fixes: 6f78193e ("HID: corsair: Add Corsair Vengeance K90 driver")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Not all platforms support DMA to the stack, and specifically since v4.9
this is no longer supported on x86 with VMAP_STACK either.

Note that the macro-mode buffer was larger than necessary.

Fixes: 6f78193e ("HID: corsair: Add Corsair Vengeance K90 driver")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See https://github.com/vlasenko/hid-asus-dkms/issues/24 for further
details.
Signed-off-by: NBrendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Make sure we have enough of a report structure to validate before
looking at it.
Reported-by: NBenoit Camredon <benoit.camredon@airbus.com>
Tested-by: NBenoit Camredon <benoit.camredon@airbus.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This headlamp contains a dummy HID descriptor which pretends to be
a mouse-like device, but can't be used as a mouse at all.
Reported-by: NLukas Ocilka <lukas.ocilka@suse.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

While applying patch d443a0aa: "HID: hid-sensor-hub: clear memory to
avoid random data", there was some issues in applying correct version of
the patch. This resulted in the breakage of sensor functions as all
request like power-up will be reset by the memset() in the function
sensor_hub_set_feature().
The reset of caller buffer should be in the function
sensor_hub_get_feature(), not in the sensor_hub_set_feature().

Fixes: d443a0aa ("HID: hid-sensor-hub: clear memory to avoid random data")
Cc: Stable <stable@vger.kernel.org> # 4.9+
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The DolphinBar by Mayflash (identified as Dragonrise) needs
HID_QUIRK_MULTI_INPUT to split it up into four input devices. Without this
quirk the adapter is falsely recognized as a tablet. See also bug 115841
(https://bugzilla.kernel.org/show_bug.cgi?id=115841).
Signed-off-by: NMarcel Hasler <mahasler@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The Futaba TOSD-5711BB VFD crashes when the initial HID report is requested,
register the display in hid-ids and tell hid-quirks to not do the init.
Signed-off-by: NAlex Wood <thetewood@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When the DS4 dongle is connected, it always generates HID reports
even when no DS4 is paired to it. This patch adds logic to ignore
HID reports from the dongle if there is no DS4 currently attached.
Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The DS4 MAC address is reported as a unique identified when
using Bluetooth. For USB there is no unique identifier reported
yet, so use the MAC address.
Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The error handling code in sony_input_configured in general uses goto
based cleanup. Recently we migrated code from sony_probe to here, but
we didn't update the existing touchpad registration code, which was
already here to use the goto.
Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The previous submission which added Touchpad support broke the
Keyboard support of this driver. This patch:
1. fixes the Keyboard support (by assigning drvdata->input);
2. renames NOTEBOOK_QUIRKS to KEYBOARD_QUIRKS;
3. adds the NO_INIT_REPORT quirk to the KEYBOARD_QUIRKS; and
4. sets the input->name to 'Asus Keyboard' for the keyboard
Signed-off-by: NBrendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

commit ba18a931 ("Revert "HID: i2c-hid: Add support for ACPI GPIO
interrupts"") removed the need for storing the irq in struct i2c_hid.

But then commit de3c99488609 ("HID: i2c-hid: Disable IRQ before freeing
buffers") forgot to update the location of the irq.

Fix this by using the actual I2C client irq.
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>

Add a forgotten include that I've by mistake omitted when resolving
merge conflict in ead0687fe30 ("HID: i2c-hid: support regulator power
on/off").

Fixes: ead0687fe30 ("HID: i2c-hid: support regulator power on/off")
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The HID report buffers that are initially allocated on i2c_hid_probe()
might not be big enough to hold the HID reports from a specific device,
in which case they will be freed and new ones will be allocated in
i2c_hid_start(), at point which the device's report size is known. But
at this point ihid->irq is already running, and may call
i2c_hid_get_input() which passes ihid->inbuf to i2c_master_recv(). Since
this handler runs in a separate thread, ihid->inbuf may be freed at this
very moment, and i2c_master_recv() will write on memory which may be
already owned by a different part of the kernel, corrupting its data.

This problem has been observed on an Asus UX360UA laptop which has an
I2C touchpad, and results in a complete system freeze or an unusable
slowness with a lof of "BUG: unable to handle kernel paging request at
<address>" warnings. Enabling SLUB debugging shows a use-after-free
warning on memory allocated in i2c_hid_alloc_buffers() and freed in
i2c_hid_free_buffers():

=============================================================================
BUG kmalloc-64 (Not tainted): Poison overwritten
-----------------------------------------------------------------------------
Disabling lock debugging due to kernel taint
INFO: 0xffff880264083273-0xffff88026408329e. first byte 0x0 instead of 0x6b
INFO: Allocated in i2c_hid_alloc_buffers+0x25/0xa0 [i2c_hid] age=35793 cpu=2 pid=430
	___slab_alloc+0x41e/0x460
	__slab_alloc+0x20/0x40
	__kmalloc+0x210/0x280
	i2c_hid_alloc_buffers+0x25/0xa0 [i2c_hid]
	i2c_hid_probe+0x12f/0x5e0 [i2c_hid]
	i2c_device_probe+0x10a/0x1b0
	driver_probe_device+0x220/0x4a0
	__device_attach_driver+0x71/0xa0
	bus_for_each_drv+0x67/0xb0
	__device_attach+0xdc/0x170
	device_initial_probe+0x13/0x20
	bus_probe_device+0x92/0xa0
	device_add+0x4aa/0x670
	device_register+0x1a/0x20
	i2c_new_device+0x18e/0x230
	acpi_i2c_add_device+0x1a0/0x210
INFO: Freed in i2c_hid_free_buffers+0x16/0x60 [i2c_hid] age=7552 cpu=1 pid=1473
	__slab_free+0x221/0x330
	kfree+0x139/0x160
	i2c_hid_free_buffers+0x16/0x60 [i2c_hid]
	i2c_hid_start+0x2a9/0x2df [i2c_hid]
	mt_probe+0x160/0x22e [hid_multitouch]
	hid_device_probe+0xd7/0x150 [hid]
	driver_probe_device+0x220/0x4a0
	__driver_attach+0x84/0x90
	bus_for_each_dev+0x6c/0xc0
	driver_attach+0x1e/0x20
	bus_add_driver+0x1c3/0x280
	driver_register+0x60/0xe0
	__hid_register_driver+0x53/0x90 [hid]
	0xffffffffc004f01e
	do_one_initcall+0xb3/0x1f0
	do_init_module+0x5f/0x1d0
INFO: Slab 0xffffea0009902080 objects=20 used=20 fp=0x          (null) flags=0x17fff8000004080
INFO: Object 0xffff880264083260 @offset=4704 fp=0x          (null)
Bytes b4 ffff880264083250: 8d e6 fe ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a  ........ZZZZZZZZ
Object ffff880264083260: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
Object ffff880264083270: 6b 6b 6b 00 00 00 00 00 00 00 00 00 00 00 00 00  kkk.............
Object ffff880264083280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880264083290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Redzone ffff8802640832a0: bb bb bb bb bb bb bb bb                          ........
Padding ffff8802640833e0: 5a 5a 5a 5a 5a 5a 5a 5a                          ZZZZZZZZ
CPU: 1 PID: 1503 Comm: python3 Tainted: G    B           4.4.21+ #10
Hardware name: ASUSTeK COMPUTER INC. UX360UA/UX360UA, BIOS UX360UA.200 05/05/2016
 0000000000000086 00000000622d48a2 ffff88026061ba38 ffffffff813f6044
 ffff880264082010 ffff880264083260 ffff88026061ba78 ffffffff811e8eab
 0000000000000008 ffff880200000001 ffff88026408329f ffff88026a007700
Call Trace:
 [<ffffffff813f6044>] dump_stack+0x63/0x8f
 [<ffffffff811e8eab>] print_trailer+0x14b/0x1f0
 [<ffffffff811e94c1>] check_bytes_and_report+0xc1/0x100
 [<ffffffff811e96c4>] check_object+0x1c4/0x240
 [<ffffffff81293fde>] ? ext4_htree_store_dirent+0x3e/0x120
 [<ffffffff811e9b44>] alloc_debug_processing+0x104/0x180
 [<ffffffff811eb7be>] ___slab_alloc+0x41e/0x460
 [<ffffffff81293fde>] ? ext4_htree_store_dirent+0x3e/0x120
 [<ffffffff8124590b>] ? __getblk_gfp+0x2b/0x60
 [<ffffffff8129b969>] ? ext4_getblk+0xa9/0x190
 [<ffffffff811eb820>] __slab_alloc+0x20/0x40
 [<ffffffff811ed320>] __kmalloc+0x210/0x280
 [<ffffffff81293fde>] ? ext4_htree_store_dirent+0x3e/0x120
 [<ffffffff812c1602>] ? ext4fs_dirhash+0xc2/0x2a0
 [<ffffffff81293fde>] ext4_htree_store_dirent+0x3e/0x120
 [<ffffffff812a4f47>] htree_dirblock_to_tree+0x187/0x1b0
 [<ffffffff812a5fd2>] ext4_htree_fill_tree+0xb2/0x2e0
 [<ffffffff811ebb7a>] ? kmem_cache_alloc_trace+0x1fa/0x220
 [<ffffffff81293e45>] ? ext4_readdir+0x775/0x8b0
 [<ffffffff81293cb1>] ext4_readdir+0x5e1/0x8b0
 [<ffffffff81221c82>] iterate_dir+0x92/0x120
 [<ffffffff81222118>] SyS_getdents+0x98/0x110
 [<ffffffff81221d10>] ? iterate_dir+0x120/0x120
 [<ffffffff818157f2>] entry_SYSCALL_64_fastpath+0x16/0x71
FIX kmalloc-64: Restoring 0xffff880264083273-0xffff88026408329e=0x6b
FIX kmalloc-64: Marking all objects used
Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Function hid_post_reset() should return negative error codes on failures.
However, in its implementation, it incorrectly returns 1.  This patch fixes the
bug, returning proper error codes on failures.
Signed-off-by: NPan Bian <bianpan2016@163.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

post input_sync only when there are input events posted
Signed-off-by: NPing Cheng <ping.cheng@wacom.com>
Reviewed-By: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Make sure everything reported from pad are registered
Signed-off-by: NPing Cheng <ping.cheng@wacom.com>
Reviewed-By: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Sometime valid events may not be supported by the driver yet. Make
sure we don't process them when the code is not ready.

This fix prevents a kernel panic due to unsupported HID events.
Signed-off-by: NPing Cheng <ping.cheng@wacom.com>
Reviewed-By: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

It is unnecessary to return a value since nothing is expecting a
value from it.
Signed-off-by: NPing Cheng <ping.cheng@wacom.com>
Reviewed-By: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

We have the %pU printf extension for doing exactly this. Saves some
.text, and is likely also a little faster.
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Since the gpio-as-irq support has been added, the driver now depends
on proper support being available in gpiolib.

Fixes: 13de9cca ("HID: cp2112: add IRQ chip handling")
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Update the hid-asus module to add multitouch support for the Asus i2c touchpad.

This patch aims to resolve the issue raised here:
https://bugzilla.kernel.org/show_bug.cgi?id=120181

The issue is in relation to an Asus touchpad device which currently does not
have multitouch support.

The device currently falls through to the hid-generic driver which
treats the device as a mouse.

This patch aims to add the multitouch support.

[jkosina@suse.cz: move most of the 'patch comment' into actual changelog]
[jkosina@suse.cz: drop hunk that changes ->name of the driver]
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NBrendan McGrath <redmcg@redmandi.dyndns.org>
Signed-off-by: NVictor Vlasenko <victor.vlasenko@sysgears.com>
Signed-off-by: NFrederik Wenigwieser <frederik.wenigwieser@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Although unlikely but it is possible that when a connect or disconnect
request is issued to the firmware, before the response comes, user
terminates the client session. In this case when the response is arrived
there is no matching client instance in the list of currently active
clients. In this case, don't issue call to wake up a waiting client.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add support for USB based DS4 dongle device, which allows connecting
a DS4 through Bluetooth, but hides Bluetooth from the host system.
Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The DS4 side of hid-sony used the hid-core layer to assign buttons
and axes based on the HID report descriptors. The default mapping
was strange e.g. right stick using ABS_Z/ABS_RZ or the physical
'south button' being reported as BTN_EAST etcetera.

This patch makes the DS4 side ofi the hid-sony driver comply to
the Linux game controller spec as suggested in a discussion with
Dmitry on the linux-input list.

Currently the main user of the DS4 is the SDL2 library, which has
a mapping table using vendor/device/version as a key. In order to
not break SDL2 we discussed adjusting the version number, so it
can have both mappings. This was discust on linux-input and we
discussed privately with SDL2 developers.
Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The dualshock 4 supports both analog sticks of which one uses
ABS_X/_Y and a touchpad. In a recent discussion with Dmitry about
some input-mt changes we proposed for disabling pointer emulation from
input_mt_sync_frame, Dmitry mentioned ABS_X/_Y should report the
same data as ABS_MT_POSITION_X/_Y. The current driver is mixing axes
for different subdevices. It was suggested to make the touchpad
its own sub-device.

This patch turns the touchpad into its own device. In addition
this patch also moves the button underneath the touchpad into
the new device. It felt like this button should be part of the
device. No known user space application (not even SDL2) seems to
be using it.
Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

A previous patch moved most input initialization from sony_probe to
sony_input_configured to avoid some race conditions. The driver has some
special logic to prevent the device to get registered twice in case the
user connects it both over Bluetooth and USB. When this condition
happens sony_input_configured returns a failure, but sony_probe continues
as hid_hw_start doesn't fail. As was discussed on linux-input, it is
acceptable for this function to fail.

This patch adds a check for the HID_CLAIMED_INPUT flag within sony_probe
to determine whether initialization succeeded correctly. The flag is
not set by the HID layer when sony_input_configured fails.
Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The GPIO part doesn't provide interrupts when GPIO are toggled.
So use a polling mechanism if someone requests a GPIO as an IRQ.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Instead of forcing the level trigger of the IRQ, we can count
on ACPI or OF to set it up for us.

The first release of the HID over I2C specification mentioned
that the level trigger needed to be active low. In the latest
version of the specification, there is no such explicit mention,
so it's better to not assume one.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

We already have in place a quirk for Windows 8 devices, but it looks
like the Surface Cover are not conforming to it.
Given that we are only interested in 3 feature reports (the ones that
the Windows driver retrieves), we should be safe to unconditionally apply
the quirk to everybody.

In case there is an issue with a controller, we can always mark it as such
in the transport driver, and hid-multitouch won't try to retrieve the
feature report.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There is no reasons to filter out keyboard and consumer control collections
in hid-multitouch.
With the previous hid-input fix, there is now a full support of the Type
Cover and we can remove all specific bits from hid-core and hid-microsoft.

hid-multitouch will automatically set HID_QUIRK_NO_INIT_REPORTS so we can
also remove it from the list of ushbid quirks.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The purpose of HID_QUIRK_MULTI_INPUT is to have an input device per
report id. This is useful when the HID device presents several HID
collections of different device types.

The current implementation of hid-input creates one input node per id per
type (input or output). This is problematic for the LEDs of a keyboard as
they are often set through an output report. The current code creates
one input node with all the keyboard keys, and one other with only the
LEDs.

To solve this, we use a two-passes way:
- first, we initialize all input nodes and associate one per report id
- then, we register all the input nodes
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

According to https://msdn.microsoft.com/en-us/library/windows/hardware/mt604195(v=vs.85).aspx
external buttons have some weird usage mapping:
- Button 2 Indicates Button State for external button for primary
  (default left) clicking.
- Button 3 Indicates Button State for external button for secondary
  (default right) clicking.

So in the current state, the buttons are mapped to right and middle.
Move the usage by one to correctly map the external buttons.
Tested-by: NChris Chiu <chiu@endlessm.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

One more device requiring a quirk :/
Reported-by: NChristian-Nils Boda <christian-nils.boda@gadz.org>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

One more device requiring a quirk :/

[jkosina@suse.cz: update comment based on Bastien's remark]
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>