The Wacom Pro Pen 3D includes a third barrel switch which is intended to
be particularly useful in applications where one frequency uses pan, zoom,
and rotate to navigate around a scene or model. The pen is compatible with
the MobileStudio Pro, 2nd-gen Intuos Pro, and Cintiq Pro. When the third
button is pressed, these devices set both the HID_DG_BARRELSWITCH and
HID_DG_BARRELSWITCH2 usages since their HID descriptors do not include a
usage specific to the button.
Rather than send both BTN_STYLUS and BTN_STYLUS2 when the third button is
pressed, userspace (libinput) has requested that we detect this condition
and report a newly-defined BTN_STYLUS3 event instead. We could define a
quirk specific to devices compatible with the Pro Pen 3D, but the liklihood
of seeing both barrel switch bits set with other pens/devices is low enough
to not worry about (pens mechanically prevent accidental activation of
multiple switches).
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This reverts commit 3e70969e44.
This commit causes a few problems for userspace. The most noteworthy are
problems related to the distinguishing of different pens and pointer jumps
when entering proximity. Userspace is written with the expectation that a
pen will provide its tool ID and serial number (if available) in the very
first in-prox report. By sending BTN_TOOL_PEN when the tablet starts
communicating rather than waiting until a tool ID/serial number is
available, userspace ends up treating all pens as being the same and
lacking a serial number. Similarly, userspace assumes that the first
report will contain X/Y data, but by marking the pen as being in-prox
without an X/Y coordinate, userspace ends up warping the pen to the last-
known X/Y location. As of commit 5b40104edf ("HID: wacom: generic: Reset
events back to zero when pen leaves") this means warping to (0,0).
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
As a pen leaves, we need to be sure to reset all events back to zero
so that userspace is able to get the complete pen state when it enters
proximity again.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When a pen is first able to to be sensed by the tablet, we would like
to inform userspace that a tool is nearby so that it can attempt to
perform palm rejection. Unfortunately, we don't know any information
about the tool that is nearby, so the best we can do is send a prox
event for a generic BTN_TOOL_PEN. If the pen later comes closer and
enters proximity, we can determine the actual tool type and send
BTN_TOOL_PEN out of prox if necessary.
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The legacy Intuos codepath and tablet behavior (e.g. the 1st-gen Intuos
Pro, Cintiq 27, etc.) would result in a BTN_TOOL_* event not being cleared
to zero until the tool had completely left the sensing range of the
tablet. Before the final "out of prox" packet would be sent, zero or
more "in range" packets could be sent to indicate that a pen was still
detectable but not within a useful distance. These "in range" packets
were used by the driver to keep touch input disabled at greater pen
distances. In addition to keeping the `stylus_in_proximity` flag set,
the driver would leave the current BTN_TOOL_* marked as being in
proximity as well.
The new HID codepath also sets `stylus_in_proximity` based on the "sense"
flag, but does not leave the current BTN_TOOL_* marked as being in prox.
This information is potentially useful to for a future userspace-based
palm rejection, so this patch modifies the driver to continue sending it.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The terminology used to describe the various degrees of pen proximity
within the wacom_wac_pen_report function does not match that used elsewhere
in the generic codepath. Specifically, the names of the variables "prox"
and "range" were inspired by the non-generic codepaths. To make the generic
codepath internally consistent, replace these terms with "range" and "sense"
respectively.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The tool ID information sent in ABS_MISC is expected to be reset to 0
when a tool leaves proximity. Not doing this can cause problems if a
tool is removed and then re-introduced. Kernel event filtering will
prevent the (identical) ABS_MISC event from being sent when the tool
re-enters proxmity. This can cause userspace to not properly set the
tool ID.
Fixes: f85c9dc678 ("HID: wacom: generic: Support tool ID and additional tool types")
Cc: stable # v4.10 <stable@vger.kernel.org>
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The latest generation of pro devices (MobileStudio Pro, 2nd-gen Intuos
Pro, Cintiq Pro) send a serial number of '0' whenever the pen is too far
away for reliable communication. Userspace defines that a serial number
of '0' is invalid, so we need to be careful not to actually forward
this value. Additionally, since EMR ISDv4 devices do not support serial
numbers or tool IDs, we'd like to not send these events if they aren't
necessary.
The existing code achieves these goals by adding a check for a non-zero
serial number within the wacom_wac_pen_report function. The MSC_SERIAL
and ABS_MISC events are only sent if the serial number is non-zero. This
code fails, however when the pen for a pro device leaves proximity. When
the pen leaves prox and the tablet sends a serial of 0, wacom_wac_pen_event
dutifully clears the serial number. When wacom_wac_pen_report is called,
it does not send either the MSC_SERIAL of the exiting tool nor an ABS_MISC
event.
This patch prevents the wacom_wac_pen_event function from clearing an
already-set serial number. This ensures that we have the serial number
handy when exiting proximity, but requires us to manually clear it
afterwards to ensure the driver does not send stale data (e.g. when
switching between AES pens that report a serial nubmer of 0 for the
first few fully in-proximity packets).
Fixes: f85c9dc678 ("HID: wacom: generic: Support tool ID and additional tool types")
Cc: stable # v4.10 <stable@vger.kernel.org>
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The buffer allocation is not currently accounting for an extra byte for
the report id. This can cause an out of bounds access in function
i2c_hid_set_or_send_report() with reportID > 15.
Cc: stable@vger.kernel.org
Signed-off-by: Adrian Salido <salidoa@google.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
So it looks like that suspend/resume has actually always been broken on
hid-rmi. The fact it worked was a rather silly coincidence that was
relying on the HID device to already be opened upon resume. This means
that so long as anything was reading the /dev/input/eventX node for for
an RMI device, it would suspend and resume correctly. As well, if
nothing happened to be keeping the HID device away it would shut off,
then the RMI driver would get confused on resume when it stopped
responding and explode.
So, call hid_hw_open() in rmi_post_resume() so we make sure that the
device is alive before we try talking to it.
This fixes RMI device suspend/resume over HID.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196851
[jkosina@suse.cz: removed useless hunk that was zero-initializing 'ret']
Signed-off-by: Lyude <lyude@redhat.com>
Cc: Andrew Duggan <aduggan@synaptics.com>
Cc: stable@vger.kernel.org
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch adds ALPS PTP sticks with pid/device id 0x120A to the list of
devices supported by hid-multitouch.
Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
On the 2nd generation Lenovo Tablet only clickpad is working; the
trackpoint and three mouse buttons do not work.
hid_multitouch must export all inputs in order to get trackpoint and
buttons to function.
Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The MobileStudio Pro, Cintiq Pro, and 2nd-gen Intuos Pro devices use a
different coordinate system for their touchring and pen twist than prior
devices. Prior devices had zero aligned to the tablet's left and would
increase clockwise. Userspace expects data from the kernel to be in this
old coordinate space, so adjustments are necessary.
While the coordinate system for pen twist is formally defined by the HID
standard, no such definition existed for the touchring at the time these
tablets were introduced. Future tablets are expected to report touchring
data using the same "zero-up clockwise-increasing" coordinate system
defined for twist.
Fixes: 50066a042d ("HID: wacom: generic: Add support for height, tilt, and twist usages")
Fixes: 4922cd26f0 ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
Fixes: 60a2218698 ("HID: wacom: generic: add support for touchring")
Cc: stable@vger.kernel.org # 4.10, 4.11
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The wacom driver's IRQ handler for Bluetooth reports from the 2nd-gen
Intuos Pro does not correctly process negative numbers. Values for
tilt and rotation (which can go negative) are instead interpreted as
unsigned and so jump to very large values when the data should be
negative. This commit properly casts the data to ensure we report
negative numbers when necessary.
Fixes: 4922cd2 ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
Cc: stable@vger.kernel.org # v4.11
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some laptops have system-control buttons (e.g. KEY_SLEEP) on the same
interface as a hid-multitouch touch-pad.
This commit fixes these buttons not working.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Ideacom 6680 touchscreen is found in the Dell Latitude 2100. It
has two USB descriptors, the first of which has two input reports. The
HID_QUIRK_MULTI_INPUT quirk is needed to keep the correct maximum
value for ABS_X/ABS_Y (8191 instead of 65535).
Signed-off-by: Nicholas Bishop <nbishop@neverware.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit a50aac7193 introduces 'led.groups' and adds EKR support
for these groups. However, unlike the other devices with LEDs,
the EKR's LEDs are read-only and we shouldn't attempt to control
them in wacom_led_control().
See bug: https://sourceforge.net/p/linuxwacom/bugs/342/
Fixes: a50aac7193 ("HID: wacom: leds: dynamically allocate LED groups")
Cc: stable <stable@vger.kernel.org> # 4.9
Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Cintiq 12 has 10 expresskey buttons. The bit shift for the last
two buttons were off by 5.
Fixes: c7f0522 ("HID: wacom: Slim down wacom_intuos_pad processing")
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Tested-by: Matthieu Robin <matthieu@macolu.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
- support for media keys on Asus T304UA from João Paulo Rechi Vita
- support for Microsoft Win8 Wireless Radio Controls extensions
from João Paulo Rechi Vita
Conflicts:
drivers/hid/hid-ids.h
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
- Arnd pointed out that driver_lock semaphore is superfluous, as
driver core already provides all the necessary concurency protection.
Removal patch from Binoy Jayan
This snd_rawmidi_ops structure is only passed as the third
argument of snd_rawmidi_set_ops. This argument is const, so the
snd_rawmidi_ops structure can be const too.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
platform_device_id are not supposed to change at runtime. All functions
working with platform_device_id provided by <linux/platform_device.h>
work with const platform_device_id. So mark the non-const structs as
const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The power_supply subsystem tends to emit uevent every time
power_supply_changed() is called, so we should call this API only when battery
strength reported by the device is actually different from the previous
readings, otherwise we'll drown the system in uevents.
Fixes: 581c448476 ("HID: input: map digitizer battery usage")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by <linux/usb.h> work with
const usb_device_id. So mark the non-const structs as const.
Fix checkpatch.pl error:
ERROR: space prohibited before open square bracket '['.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by <linux/usb.h> work with
const usb_device_id. So mark the non-const structs as const.
Fix checkpatch.pl error:
ERROR: space prohibited before open square bracket '['.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In the reference HID sensor hub firmware all Named array enums were
0-based. There is no description of the default base of enums in HID
sensor hub specification as logical minimum should have set this base
value.
Every sensor hub implemented enum as 1-based, without explicitly setting
logical minimum to 1, because of the implementation by one of the major
OS vendor. In Linux we used logical minimum to decide the enum base.
Some sensor hub FWs already changed logical minimum from 0 to 1. We hoped
that every other vendor will follow. But that didn't happen and we had to
fix the report header for every sensor hub to change logical minimum to 1
by using .report_fixup() callback. So for every new sensor hub we had to
modify source code by adding this quirk based on the vendor and device id.
This is becoming a maintenance burden.
This patch hardcodes the logical minimum of power and report state
attributes to 1. In this way we can remove the existing quirks and also
we don't have to add more quirks.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The WACOM_HID_WD_TOUCHRINGSTATUS usage is a single bit which tells us
whether the touchring is currently in use or not. Because we need to
reset the axis value to 0 when the finger is removed, we call
'wacom_map_usage' to ensure that the required type/code values are
associated with the usage. The 'wacom_map_usage' also sets up the axis
range and resolution, however, which is not desired in this particular
case.
Although xf86-input-wacom doesn't do really do anything with the ring's
range or resolution, the libinput driver (for Wayland environments)
uses these values to provide proper angle indications to userspace.
Fixes: 60a2218698 ("HID: wacom: generic: add support for touchring")
Cc: stable@vger.kernel.org
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Put the touchpad in native (absolute coordinate mode) and export it to
userspace as a touchpad rather then as a mouse.
Note this requires HID_QUIRK_MULTI_INPUT as the T100CHI keyboard dock
has all functionality on a single HID interface and userspace expects
touchpads to be on a separate input_dev. Without MULTI_INPUT userspace
will ignore the keyboard part of the keyboard/touchpad combo.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by <linux/sysfs.h> work with
const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by <linux/sysfs.h> work with
const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by <linux/sysfs.h> work with
const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by <linux/sysfs.h> work with
const attribute_group. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
0xff310076 application has been defined by 957b8dffa4 ("HID: multitouch:
Support Asus T304UA media keys") as a vendor-specific application with
symbolic constant HID_VD_ASUS_CUSTOM_MEDIA_KEYS, so let's make use of
it.
Fixes: 957b8dffa4 ("HID: multitouch: Support Asus T304UA media keys")
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Asus T304UA convertible sports a magnetic detachable keyboard with
touchpad, which is connected over USB. Most of the keyboard hotkeys are
exposed through the same USB interface as the touchpad, defined in the
report descriptor as follows:
0x06, 0x31, 0xFF, // Usage Page (Vendor Defined 0xFF31)
0x09, 0x76, // Usage (0x76)
0xA1, 0x01, // Collection (Application)
0x05, 0xFF, // Usage Page (Reserved 0xFF)
0x85, 0x5A, // Report ID (90)
0x19, 0x00, // Usage Minimum (0x00)
0x2A, 0xFF, 0x00, // Usage Maximum (0xFF)
0x15, 0x00, // Logical Minimum (0)
0x26, 0xFF, 0x00, // Logical Maximum (255)
0x75, 0x08, // Report Size (8)
0x95, 0x0F, // Report Count (15)
0xB1, 0x02, // Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0x05, 0xFF, // Usage Page (Reserved 0xFF)
0x85, 0x5A, // Report ID (90)
0x19, 0x00, // Usage Minimum (0x00)
0x2A, 0xFF, 0x00, // Usage Maximum (0xFF)
0x15, 0x00, // Logical Minimum (0)
0x26, 0xFF, 0x00, // Logical Maximum (255)
0x75, 0x08, // Report Size (8)
0x95, 0x02, // Report Count (2)
0x81, 0x02, // Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0xC0, // End Collection
This UsagePage is declared as a variable, but we need to treat it as an
array to be able to map each Usage we care about to its corresponding
input key.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some keyboard + touchpad devices have the Microsoft Win8 Wireless Radio
Controls extensions Usage Page define in the touchpad report descriptor,
so we need to support them in this driver.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Manufacturers do not always populate serial number in their devices, so
let's fall back to device ID when forming the battery device name. As a
result, batteries in devices without serial number will be named like
this:
hid-0018:2D1F:510E.0001-battery
(as opposed to hid--battery for the first one, and failing to create
batteries for the subsequent ones).
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We already mapped battery strength reports from the generic device
control page, but we did not update capacity from input reports, nor we
mapped the battery strength report from the digitizer page, so let's
implement this now.
Batteries driven by the input reports will now start in "unknown" state,
and will get updated once we receive first report containing battery
strength from the device.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The semaphore 'driver_lock' is used as a simple mutex, and also unnecessary as
suggested by Arnd. Hence removing it, as the concurrency between the probe and
remove is already handled in the driver core.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Binoy Jayan <binoy.jayan@linaro.org>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The driver has gained a compile-time dependency that we should
express in Kconfig to avoid this link error:
drivers/hid/wacom_sys.o: In function `wacom_parse_and_register':
wacom_sys.c:(.text+0x2eec): undefined reference to `usb_hid_driver'
Fixes: 09dc28acae ("HID: wacom: Improve generic name generation")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Without a quirk or the X Window System, this device disconnects every
60 seconds. This patch also renames the define associated with the
Logitech 0xc007 product ID, which appeared to have a conflicting typo.
Cc: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Kyle Roarty <kroarty@xes-inc.com>
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The 'wacom_update_name' function is responsible for producing names for
the input device nodes based on the hardware device name. Commit f2209d4
added the ability to strip off prefixes like "Wacom Co.,Ltd." where the
prefix was immediately (and redundantly) followed by "Wacom". The
2nd-generation Intuos Pro 2 has such a prefix, but with a small error
(the period and comma are swapped) that prevents the existing code from
matching it. We're loath to extend the number of cases out endlessly and
so instead try to be smarter about name generation.
We observe that the cause of the redundant prefixes is HID combining the
manufacturer and product strings of USB devices together. By using the
original product name (with "Wacom" prefixed, if it does not already
exist in the string) we can bypass the gyrations to find and remove
redundant prefixes. Other devices either don't have a manufacturer string
that needs to be removed (Bluetooth, uhid) or should have their name
generated from scratch (I2C).
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Acked-By: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Although HID itself is transport-agnostic, occasionally a driver may
want to interact with the low-level transport that a device is connected
through. To do this, we need to know what kind of bus is in use. The
first guess may be to look at the 'bus' field of the 'struct hid_device',
but this field may be emulated in some cases (e.g. uhid).
More ideally, we can check which ll_driver a device is using. This
function introduces a 'hid_is_using_ll_driver' function and makes the
'struct hid_ll_driver' of the four most common transports accessible
through hid.h.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Acked-By: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The iHome keypad also requires the same tweak we are doing for other
Ortek devices.
Reported-by: Mairin Duffy <duffy@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Even though the IO for devices with "always poll" quirk is already running,
we still need to set HID_OPENED bit in usbhid->iofl so the interrupt
handler does not ignore the data coming from the device.
Reported-by: Olof Johansson <olof@lixom.net>
Tested-by: Olof Johansson <olof@lixom.net>
Fixes: e399396a6b ("HID: usbhid: remove custom locking from usbhid_open...")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
