The monitor interface on the wireless receiver is more logically expressed
as a type of device instead of a quirk.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

Commit 01c846f9 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: NJason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

The HID_DG_WIDTH and HID_DG_HEIGHT usages report with width and height of
contacts. From this information, a crude determination of orientation is
also possible. This patch reports all three to userspace if a device
reports this usage.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

The reports sent from some touch devices (e.g. the Cintiq 24HDT) contain
junk data in the contact slots which follow the final "valid" contact.
To avoid forwarding it to usrspace, we store the reported contact count
during the pre-process phase and then only process that many contacts.
If a device sends its contacts across multiple reports (what Microsoft
refers to as "hybrid" mode) then the contact count will be zero for
reports other than the first.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

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: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

Allocated input devices should not use the 'pen_name' by default since
we do not know at that point in time if that is an appropriate choice
of name. Instead, use the (tool-agnostic) name that is stored in the
device's 'wacom_features' structure. This also has the nice side-effect
of requring us to be explicit about the naming of the pen device, as
we already are for touch and pad devices.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

The 'wacom_allocate_inputs' function tries to allocate three input devices: one
each for the pen, touch, and pad. The pointers that are returned by the
'wacom_allocate_input' calls are temporarily stored to local variables where
they are checked to ensure they're non-null before storing them in the
'wacom_wac' structure. If an allocation fails,  the 'wacom_free_inputs'
function is called to reclaim the memory. Unfortunately, 'wacom_free_inputs' is
called prior to the pointers being copied, so it is not actually able to free
anything.

This patch has the calls to 'wacom_allocate_input' store the pointer directly
in the 'wacom_wac' structure where they can be freed. Also, it replaces the
call to 'wacom_free_inputs' with the (more general) 'wacom_clean_inputs' and
removes the no-longer-used function.

[jkosina@suse.com: modify to resolve conflict with 67e123ff ("Delete
 unnecessary checks")]
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

As mentioned in the comment in the code, both the pen and touch data
come from the interface tagged as BAMBOO_PAD. The driver re-routes the
events for the Pen to the generic HID interface and keeps the ones for
the touch through this current interface.

Clearing the WACOM_DEVICETYPE_PEN bit removes the extra unused interface
added in 2a6cdbdd ("HID: wacom: Introduce new 'touch_input' device") and
makes the Bamboo PAD to behave like in 4.1.
Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

We need to emit EV_SYN/SYN_REPORT between key press and release, otherwise
userspace is allowed to "swallow" the event.

[jkosina@suse.com: Dmitry says that he's observing this behavior with
 Plantronics headset]
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

The input_free_device() function tests whether its argument is NULL and
then returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

During open() it is unnecessary to wait for the device to flush
stale inputs if the device is polled while closed due to a quirk
or opening fails.
Signed-off-by: NOliver Neukum <oneukum@suse.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

Use kernel.h macro definition.

Thanks to Julia Lawall for Coccinelle scripting support.
Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Adding support for the Microsoft Surface Pro Power Cover.
Signed-off-by: NRaimund Roth <raimundmroth@gmail.gom>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Patch report descriptor to remove unused and ramdomly changing axis.

Original report descriptor (via BT) was as follows:
00000000  05 01 09 04 a1 01 a1 02  85 01 75 08 95 01 15 00  |..........u.....|
00000010  26 ff 00 81 03 75 01 95  13 15 00 25 01 35 00 45  |&....u.....%.5.E|
00000020  01 05 09 19 01 29 13 81  02 75 01 95 0d 06 00 ff  |.....)...u......|
00000030  81 03 15 00 26 ff 00 05  01 09 01 a1 00 75 08 95  |....&........u..|
00000040  04 35 00 46 ff 00 09 30  09 31 09 32 09 35 81 02  |.5.F...0.1.2.5..|
00000050  c0 05 01 75 08 95 27 09  01 81 02 75 08 95 30 09  |...u..'....u..0.|
00000060  01 91 02 75 08 95 30 09  01 b1 02 c0 a1 02 85 02  |...u..0.........|
00000070  75 08 95 30 09 01 b1 02  c0 a1 02 85 ee 75 08 95  |u..0.........u..|
00000080  30 09 01 b1 02 c0 a1 02  85 ef 75 08 95 30 09 01  |0.........u..0..|
00000090  b1 02 c0 c0 00                                    |.....|
00000095
Signed-off-by: NSimon Wood <simon@mungewell.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NSimon Wood <simon@mungewell.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NSimon Wood <simon@mungewell.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Instead of having a single 'input_dev' device that will take either pen
or touch data depending on the type of the device, create seperate devices
devices for each. By splitting things like this, we can support devices
(e.g. the I2C "AES" sensors in some newer tablet PCs) that send both pen
and touch reports from a single endpoint.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This splits the 'wacom_setup_pentouch_input_capabilites' function into
pieces dedicated to doing setup for just the pen interface and just
the touch interface. This makes it easier to focus on the relevant
piece when making changes.

This patch introduces no functional changes.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Historically, both the touch and pad tools would have shared the
'BTN_TOOL_FINGER' type. Any time you needed to distinguish the two, you
had to use some other bit of knowledge (e.g. that the pad was on the same
interface as the pen, and thus 'touch_max' would be zero).

To make these checks more readable, we introduce WACOM_DEVICETYPE_PAD.
Although we still have to rely on other bits of knowledge to set this
bit on the right interface (since it cannot be detected from the HID
descriptor), it can be done just once inside 'wacom_setup_device_quirks'.

This patch introduces no functional changes.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The USB devices that this driver has historically supported segregate the
pen and touch portions of the tablet. Oftentimes the segregation would be
done at the interface level, though on occasion (e.g. Cintiq 24HDT) the
tablet would combine two totally independent USB devices behind an internal
USB hub. Because pen and touch never shared the same interface, it made
sense for the 'device_type' to store a single value: "pen" or "touch".

Recently, however, some I2C devices have been created which combine the
two. A first step to accomodating this is to expand 'device_type' so that
it can represent two (or potentially more) types simultaneously. To do
this, we treat it as a bitfield and set/check individual bits rather
than using the '=' and '==' operators.

This should not result in any functional change since no supported devices
(that I'm aware of, at least) have HID descriptors that indicate both
pen and touch reports on a single interface.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

A little bit of cleanup work for 'wacom_update_name' to make it easier on
the eyes. Creates a temporary 'name' variable on which we'll perform our
edits. Once the name is in its final form, it will be copied (with
appropriate suffix) to 'wacom_wac->name' and 'wacom_wac->pad_name'.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Physical buttons do not use F30 to report their state and in some cases the
data reported in F30 is incorrect and inconsistent with what is reported by
the HID descriptor. When physical buttons are present, ignore F30 and let
hid-input report buttons based on what is defined in the HID descriptor.
Signed-off-by: NAndrew Duggan <aduggan@synaptics.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Update Kconfig with enhanced help text for hid-plantronics driver.

Update hid-plantronics.c to identify device type and correctly map
either the vendor unique or consumer control volume up/down usages
to KEY_VOLUMEUP and KEY_VOLUMEDOWN events. Unmapped usages are ignored
to prevent core mapping of unknown usages to random mouse events.

Tested on ChromeBox/ChromeBook with various Plantronics devices.
Signed-off-by: NTerry Junge <terry.junge@plantronics.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Fix the report descriptor so that the buttons and trigger are correctly reported.

The format of the input report is described here:
https://github.com/nitsch/moveonpc/wiki/Input-report

The Accelerometers and Gyros (1st frame only) are also reported as axis, but
the Magnetometers are NOT as 'fixing' their byte order would break user-space
drivers such as PSMoveAPI.

It is hoped to resolve this at a future time.
Signed-off-by: NSimon Wood <simon@mungewell.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The LED and Rumble control only function via BT if the full output report
is sent. The large report still functions via USB.
Signed-off-by: NSimon Wood <simon@mungewell.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add support for the battery charge level and state to be read via BT.

This is not support via USB as there is no know way to get the device
sending 'input' reports over USB.
Signed-off-by: NSimon Wood <simon@mungewell.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Split quirk for PS Move Controller as it has to be treated differently
when connected via BT.
Signed-off-by: NSimon Wood <simon@mungewell.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NSimon Wood <simon@mungewell.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The HID device does not need to know about the ACPI device associated with
the underlying i2c device. Setting the ACPI companion field in the HID device
also has the side effect of causing HID to be set as wake capable, since
acpi_bind_one uses's the companion ACPI device's wakeup flags to set the
device as wake capable. Which results in power/wakeup files in sysfs for
the HID device which do not do anything.
Signed-off-by: NAndrew Duggan <aduggan@synaptics.com>
Reviewed-by: NBenson Leung <bleung@chromium.org>
Tested-by: NBenson Leung <bleung@chromium.org>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Removes Vernier Software & Technology devices from the ldusb
driver and the hid_ignore_list table of the usbhid driver in the
Linux tree.  These devices will now be supported via the hidraw
driver.

A user space driver for these devices will be found in the
Go! Software Development Kit from Vernier at
http://www.vernier.com/downloads/software-development-kits/go-sdk/.
These devices are also be supported by the LabQuest2 standalone
interface shown at http://www.vernier.com/products/interfaces/labq2/
and the LoggerPro for Linux software shown at
http://www.vernier.com/downloads/logger-pro-linux/.
Signed-off-by: NDennis O'Brien <dennis.obrien@eqware.net>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The Logitech M560 is a wireless mouse designed for windows 8 which uses
the unifying receiver.
Compared to a standard one, some buttons (the middle one and the
two ones placed on the side) are bound to a key combination
instead of a generating classic "mouse" button events.

The device shows up as a mouse and keyboard combination: when the middle
button is pressed it sends a key (as keyboard) combination, the same
happens for the two side button. The left/right/wheel work as expected
from a mouse. To complicate things further, the middle button sends
different keys combinations between odd and even presses.
In the "even" press it also sends a left click. But the worst thing
is that no event is generated when the middle button is released.

It is possible to re-configure the mouse sending a command (see function
m560_send_config_command()). After this command the mouse sends some
useful data when the buttons are pressed and/or released.

[jkosina@suse.cz: fix build breakage due to leftover from previous
 patch version]
Signed-off-by: NGoffredo Baroncelli <kreijack@inwind.it>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Rename the function extract() to hid_field_extract(), make it external linkage
to allow the use from other modules.
Suggested-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NGoffredo Baroncelli <kreijack@inwind.it>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There is no sysfs_group_remove() on failure path in lenovo_probe_tpkbd().

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This line is too long; split it up.
Signed-off-by: NJames C Boyd <jcboyd.dev@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There are too many bangs in this conditional; therefore
remove them while still maintaining the same logic.
Signed-off-by: NJames C Boyd <jcboyd.dev@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

GCC reports a -Wlogical-not-parentheses warning here; therefore
add parentheses to shut it up and to express our intent more.
Signed-off-by: NJames C Boyd <jcboyd.dev@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Most of the entries are aligned with TABs, fix those which are not.
Signed-off-by: NAntonio Ospite <ao2@ao2.it>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

I received a report from an user of following mouse which needs this quirk:

usb 1-1.6: USB disconnect, device number 58
usb 1-1.6: new low speed USB device number 59 using ehci_hcd
usb 1-1.6: New USB device found, idVendor=04f2, idProduct=1053
usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.6: Product: USB Optical Mouse
usb 1-1.6: Manufacturer: PixArt
usb 1-1.6: configuration #1 chosen from 1 choice
input: PixArt USB Optical Mouse as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input5887
generic-usb 0003:04F2:1053.16FE: input,hidraw2: USB HID v1.11 Mouse [PixArt USB Optical Mouse] on usb-0000:00:1a.0-1.6/input0

The quirk was tested by the reporter and it fixed the frequent disconnections etc.

[jkosina@suse.cz: reorder the position in hid-ids.h]
Signed-off-by: NHerton R. Krzesinski <herton@redhat.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Hardware may not respond to a request for the HID_DG_CONTACTMAX feature and
we should be tolerant of such a failure. This is especially true when using
hid-replay where the hardware doesn't exist, but also for devices attached
to a flaky bus. This patch increases the number of allowable retries to
match other calls to 'wacom_get_report' and also provides a fallback which
forces 'touch_max = 16' (enough for any Wacom device seen so far).
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Retrying on -EPIPE makes very little sense since this typically indicates
a problem that will not just disappear on its own. For instance, the USB
documentation states that it will be sent if the endpoint is stalled or
the device has disconnected. Instead, we should retry if -EAGAIN is
received since this indicates a temporary error condition such as a busy
bus.

In addition to adjusting the conditions we retry under, we also log an
error on failure so that we can be aware of what's going on.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>