Rename the device ID macro for the second version of KYE MousePen i608x
graphics tablet to have "V" in its name to signify that "2" is a
version.
I.e. USB_DEVICE_ID_KYE_MOUSEPEN_I608X_2 ->
USB_DEVICE_ID_KYE_MOUSEPEN_I608X_V2
This also makes applying additional fixes from DIGImend easier.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Adding support for the Microsoft Surface 4 Type Cover Pro (JP).
Signed-off-by: Yuta Kobayashi <alu.ula@outlook.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch validates the num_values parameter from userland during the
HIDIOCGUSAGES and HIDIOCSUSAGES commands. Previously, if the report id was set
to HID_REPORT_ID_UNKNOWN, we would fail to validate the num_values parameter
leading to a heap overflow.
Cc: stable@vger.kernel.org
Signed-off-by: Scott Bauer <sbauer@plzdonthack.me>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
These devices feature multiple interfaces/endpoints: a legacy BIOS/boot
interface (endpoint 0x81), as well as 2 corsair-specific keyboard interfaces
(endpoint 0x82, 0x83 IN/0x03 OUT) and an RGB LED control interface (endpoint
0x84 IN/0x04 OUT)
Because the extra 3 interfaces are not of subclass USB_INTERFACE_SUBCLASS_BOOT,
HID_QUIRK_NOGET is not automatically set on them and a 10s timeout per-endpoint
(30s per device) occurs initialising reports on boot. We configure
HID_QUIRK_NO_INIT_REPORTS for these devices.
Additionally the left-side G1-G18 macro keys on the K95RGB generate output on
the un-opened 0x82/0x83 endpoints which causes the keyboard to stop responding
waiting for this event to be collected. We enable HID_QUIRK_ALWAYS_POLL to
prevent this situation from occurring.
Signed-off-by: Trent Lloyd <trent@lloyd.id.au>
Tested-by: SUGNIAUX Wilfried <wsu@ppharm2k20.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Needed for v2 of the device firmware, otherwise kernel will stuck for few
seconds and throw "usb_submit_urb(ctrl) failed: -1" early on system boot.
Signed-off-by: Nazar Mokrynskyi <nazar@mokrynskyi.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The usbhid driver has inconsistently duplicated code in its post-reset,
resume, and reset-resume pathways.
reset-resume doesn't check HID_STARTED before trying to
restart the I/O queues.
resume fails to clear the HID_SUSPENDED flag if HID_STARTED
isn't set.
resume calls usbhid_restart_queues() with usbhid->lock held
and the others call it without holding the lock.
The first item in particular causes a problem following a reset-resume
if the driver hasn't started up its I/O. URB submission fails because
usbhid->urbin is NULL, and this triggers an unending reset-retry loop.
This patch fixes the problem by creating a new subroutine,
hid_restart_io(), to carry out all the common activities. It also
adds some checks that were missing in the original code:
After a reset, there's no need to clear any halted endpoints.
After a resume, if a reset is pending there's no need to
restart any I/O until the reset is finished.
After a resume, if the interrupt-IN endpoint is halted there's
no need to submit the input URB until the halt has been
cleared.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Daniel Fraga <fragabr@gmail.com>
Tested-by: Daniel Fraga <fragabr@gmail.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The device which identifies itself as a "USB Keykoard" (no typo)
with VID:PID 1a2c:0027 does not seem to be handling the reports
initialization very well.
This results in a "usb_submit_urb(ctrl) failed: -1" message from the
kernel when connected, and a delay before its initialization. It can
also cause the hang the system.
This patch adds the quirk for this device, which causes the delay
to disappear. It is named as "USB Keykoard2" because the "USB Keykoard"
already exists.
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The midi controller times-out while initializing reports, this
causes boot to take an extra 10 seconds. The device descriptor
advertises that it has an internal HID device but seems to not
actually do anything useful.
Signed-off-by: Stafford Horne <shorne@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull HID updates from Jiri Kosina:
- appoint Benjamin Tissoires as co-maintainer / designated reviewer
- sysfs report_descriptor visibility fix for unclaimed devices, from
Andy Lutomirski
- suspend/resume fixes for Sony driver from Frank Praznik
- IRQ deadlock fix from Ioan-Adrian Ratiu
- hid-i2c fixes affecting (at least) Yoga 900 from Mika Westerberg and
Srinivas Pandruvada
- a lot of new device support (especially, but not limited to, Wacom)
and assorted small misc fixes
- almost complete G920 support; the only bit that is missing is
switching the device to HID mode automatically; Simon Wood and Michal
Maly are working on it.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (46 commits)
Revert "INPUT: xpad: switch Logitech G920 Wheel into HID mode"
HID: sensor-hub: Add quirk for Lenovo Yoga 900 with ITE Chips
HID: Add new PID for Microchip Pick16F1454
HID: wacom: Use correct report to query pen ID from INTUOSHT2 devices
HID: i2c-hid: Prevent sending reports from racing with device reset
HID: use kobj_to_dev()
HID: wiimote: use dev_to_wii()
HID: add a new helper to_hid_driver()
HID: use to_hid_device()
HID: move to_hid_device() to hid.h
HID: usbhid: use to_usb_device
HID: corsair: Convert to use module_hid_driver
HID: input: ignore the battery in OKLICK Laser BTmouse
HID: wacom: Fix pad button range for CINTIQ_COMPANION_2
HID: wacom: Fix touchring value reporting
HID: wacom: Report 'strip2' values in ABS_RY
HID: wacom: Limit touchstrip data to 13 bits
HID: wacom: bitwise vs logical ORs
HID: wacom: Apply lowres quirk to BAMBOO_TOUCH devices
HID: enable hid device to suspend/resume asynchronously
...
Here are a number of small USB fixes for 4.4-rc5. All of them have been
in linux-next. The majority are gadget and phy issues, with a few new
quirks and device ids added as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlZs8fkACgkQMUfUDdst+ym/HwCgxdhop3PMk9QxCVaEdxcqv10p
PDkAn0uOW1sdRsHVRhutjcc29+AUJggk
=ybrB
-----END PGP SIGNATURE-----
Merge tag 'usb-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB driver fixes from Greg KH:
"Here are a number of small USB fixes for 4.4-rc5. All of them have
been in linux-next. The majority are gadget and phy issues, with a
few new quirks and device ids added as well"
* tag 'usb-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (32 commits)
USB: add quirk for devices with broken LPM
xhci: fix usb2 resume timing and races.
usb: musb: fail with error when no DMA controller set
usb: gadget: uvc: fix permissions of configfs attributes
usb: musb: core: Fix pm runtime for deferred probe
usb: phy: msm: fix a possible NULL dereference
USB: host: ohci-at91: fix a crash in ohci_hcd_at91_overcurrent_irq
usb: Quiet down false peer failure messages
usb: xhci: fix config fail of FS hub behind a HS hub with MTT
xhci: Fix memory leak in xhci_pme_acpi_rtd3_enable()
usb: Use the USB_SS_MULT() macro to decode burst multiplier for log message
USB: whci-hcd: add check for dma mapping error
usb: core : hub: Fix BOS 'NULL pointer' kernel panic
USB: quirks: Apply ALWAYS_POLL to all ELAN devices
usb-storage: Fix scsi-sd failure "Invalid field in cdb" for USB adapter JMicron
USB: quirks: Fix another ELAN touchscreen
usb: dwc3: gadget: don't prestart interrupt endpoints
USB: serial: Another Infineon flash loader USB ID
USB: cdc_acm: Ignore Infineon Flash Loader utility
USB: cp210x: Remove CP2110 ID from compatibility list
...
All ELAN hid devices seem to require the ALWAYS_POLL quirk. Let's use
this quirk for all devices from this vendor, rather than maintaining a
list of all its known product IDs.
Tested-by: Adrien Vergé <adrienverge@gmail.com>
Signed-off-by: Adrien Vergé <adrienverge@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The critical section protected by usbhid->lock in hid_ctrl() is too
big and because of this it causes a recursive deadlock. "Too big" means
the case statement and the call to hid_input_report() do not need to be
protected by the spinlock (no URB operations are done inside them).
The deadlock happens because in certain rare cases drivers try to grab
the lock while handling the ctrl irq which grabs the lock before them
as described above. For example newer wacom tablets like 056a:033c try
to reschedule proximity reads from wacom_intuos_schedule_prox_event()
calling hid_hw_request() -> usbhid_request() -> usbhid_submit_report()
which tries to grab the usbhid lock already held by hid_ctrl().
There are two ways to get out of this deadlock:
1. Make the drivers work "around" the ctrl critical region, in the
wacom case for ex. by delaying the scheduling of the proximity read
request itself to a workqueue.
2. Shrink the critical region so the usbhid lock protects only the
instructions which modify usbhid state, calling hid_input_report()
with the spinlock unlocked, allowing the device driver to grab the
lock first, finish and then grab the lock afterwards in hid_ctrl().
This patch implements the 2nd solution.
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
If an event is discarded the device stays idle. Just reverse the order of
check and marking busy.
Found by code inspection.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Without quirk keyboard repeats '6' until volume control is used since it
indicates the key is pressed without ever releasing.
Signed-off-by: Jimmy Berry <jimmy@boombatower.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The WiiU adapter from Mayflash (see
http://www.mayflash.com/Products/NINTENDOWiiU/W009.html) is not
working correctly.
The "XInput" mode works fine, the controller is recognized as a xbox
controller. But it is only possible to connect one controller with this method.
In "DInput" mode the device is recognized as some kind of mouse input but no
joystick is created. This commit will change this behavior with
HID_QUIRK_MULTI_INPUT to split the device into 4 input devices so that it will
also create joysticks in /dev/input/js*.
Signed-off-by: Oliver Schmitt <voltumna@gmx.net>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Adds support for Microsoft Type Cover 3 with 0x07e2 product ID.
Signed-off-by: Donavan Lance <shvr@fedoraproject.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Looks like 0x8882 needs the same quirk than 0x8883.
Given that both devices claim they are "TPV OpticalTouchScreen" rename
the 0x8883 to add its PID in the #define.
Reported-by: Blaine Lee <blaine.j.lee@medtronic.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
It was reported that after 10-20 reboots, a usb keyboard plugged
into a docking station would not work unless it was replugged in.
Using usbmon, it turns out the interrupt URBs were streaming with
callback errors of -71 for some reason. The hid-core.c::hid_io_error was
supposed to retry and then reset, but the reset wasn't really happening.
The check for HID_NO_BANDWIDTH was inverted. Fix was simple.
Tested by reporter and locally by me by unplugging a keyboard halfway until I
could recreate a stream of errors but no disconnect.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Adding support for the Microsoft Surface 3 (non-pro) Type Cover.
The existing definitions and quirks are actually for the Surface
Pro 3 type covers. I've renamed the old constants to reflect that
they belong to the Surface Pro 3, and added a new constant and
matching code for the Surface 3.
Signed-off-by: Stephen Just <stephenjust@gmail.com>
Signed-off-by: Jiri 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: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The newer firmware on MS Surface 2 tablets causes the type and touch cover keyboards to timeout when waiting for reports.
The quirk HID_QUIRK_NO_INIT_REPORTS allows them to function normally.
Signed-off-by: Reyad Attiyat <reyad.attiyat@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Adding support for the Microsoft Surface Pro Power Cover.
Signed-off-by: Raimund Roth <raimundmroth@gmail.gom>
Signed-off-by: Jiri 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: Herton R. Krzesinski <herton@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Like other KVM switches, the Aten DVI KVM switch needs a quirk to avoid spewing
errors:
[791759.606542] usb 1-5.4: input irq status -75 received
[791759.614537] usb 1-5.4: input irq status -75 received
[791759.622542] usb 1-5.4: input irq status -75 received
Add it.
Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The raphnet.net 4nes4snes and 2nes2snes multi-joystick adapters use a single
HID report descriptor with one report ID per controller. This has the effect
that the inputs of otherwise independent game controllers get packed in one
large joystick device.
With this patch each controller gets its own /dev/input/jsX device, which is
more natural and less confusing than having all inputs going to the same place.
Signed-off-by: Raphael Assenat <raph@raphnet.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The device exists with two device IDs instead of one as previously
believed.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
During a stress test these mice kept dropping and reappearing
in runlevel 1 as opposed to 5.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Force-beedback core guarantees that the 'effect' pointer that's being passed
to ->upload() callback is non-NULL.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jiri 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: Oliver Neukum <oneukum@suse.de>
CC: stable@vger.kernel.org
Signed-off-by: Jiri 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: Jim Keir <jimkeir@oracledbadirect.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Based on a patch from: Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com>
Most of the tablets handled by hid-uclogic already use MULTI_INPUT.
For the ones which are not quirked in usbhid/hidquirks, they have a
custom report descriptor which contains only one report per HID
interface. For those tablets HID_QUIRK_MULTI_INPUT is transparent.
According to https://github.com/DIGImend/tablets, the only problematic
tablet currently handled by hid-uclogic is the TWHA60 v3. This tablet
presents different report descriptors from the ones currently quirked.
This is not a problem per se, given that this tablet is not supported
currently in this version (it needs the same command as a Huion to
start forwarding events).
Reviewed-by: Nikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Genius PenSketch M912 digitizer tablet sends incorrect report descriptor by
default. This patch replaces it with a corrected one.
Signed-off-by: Milan Plzik <milan.plzik@gmail.com>
Reviewed-by: Nikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The FF2 driver (usbhid/hid-pidff.c) sends commands to the stick during ff_init.
However, this is called inside a block where driver_input_lock is locked, so
the results of these initial commands are discarded. This behavior is the
"killer", without this nothing else works.
ff_init issues commands using "hid_hw_request". This eventually goes to
hid_input_report, which returns -EBUSY because driver_input_lock is locked. The
change is to delay the ff_init call in hid-core.c until after this lock has
been released.
Calling hid_device_io_start() releases the lock so the device can be
configured. We also need to call hid_device_io_stop() on exit for the lock to
remain locked while ending the init of the drivers.
[ benjamin.tissoires@redhat.com: imrpoved the changelog a lot ]
Signed-off-by: Jim Keir <jimkeir@oracledbadirect.com>
Reviewed-by: Benjamin.tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Use <driver>-$(CONFIG_FOO) syntax to build multipart objects with
optional parts, since all the config options are bool. Also, delete the
obvious comments in the usbhid Makefile.
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Based on code for the US Surface Type Cover 3
from commit be3b16341d
("HID: add support for MS Surface Pro 3 Type Cover"):
Signed-off-by: Alan Wu <alan.c.wu@gmail.com>
Tested-by: Karlis Dreizis <karlisdreizis@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
New Genius MousePen i608X devices have a new id 0x501a instead of the
old 0x5011 so add a new #define with "_2" appended and change required
places.
The remaining two checkpatch warnings about line length
being over 80 characters are present in the original files too and this
patch was made in the same style (no line break).
Just adding a new id and changing the required places should make the
new device work without any issues according to the bug report in the
following url.
This patch was made according to and fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=67111
Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In several hid drivers it is necessary to calculate the length of an
hid_report. This patch exports the existing static function hid_report_len of
hid-core.c as an inline function in hid.h
Signed-off-by: Mathieu Magnaudet <mathieu.magnaudet@enac.fr>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The touchscreen needs the same quirk as the other models.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Reported-by: Bryan Poling <poli0048@umn.edu>
CC: stable@vger.kernel.org
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Yet another device that needs this quirk.
Reported-by: Tanguy de Baritault <tdebaritault@gmail.com>
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When events occurs while no one is listening to the node (hid->open == 0
and usb_kill_urb() called) some events are still stacked somewhere in
the USB (kernel or device?) stack. When the node gets reopened, these
events are drained, and this results in spurious touch down/up, or mouse
button clicks.
The problem was spotted with touchscreens in fdo bug #81781 [1], but it
actually occurs with any mouse using hid-generic or touchscreen.
A way to reproduce it is to call:
$ xinput disable 9 ; sleep 5 ; xinput enable 9
With 9 being the device ID for the touchscreen/mouse. During the "sleep",
produce some touch events or click events. When "xinput enable" is called,
at least one click is generated.
This patch tries to fix this by draining the queue for 50 msec and
during this time frame, not forwarding these old events to the hid layer.
Hans completed the explanation:
"""
Devices like mice (basically any hid device) will have a fifo
on the device side, when we stop submitting urbs to get hid reports from
it, that fifo will fill up, and when we resume we will get whatever
is there in that fifo.
"""
[1] https://bugs.freedesktop.org/show_bug.cgi?id=81781
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This device needs the quirk as well.
Tested-by: Kevin Fenzi <kevin@scrye.com>
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There is a second mouse sharing the same vendor strings but different IDs.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This mouse keeps disconnecting in runlevel 3. It needs the ALWAYS_POLL quirk.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Enable the always-poll quirk for Elan Touchscreens found on some recent
Samsung laptops.
Without this quirk the device keeps disconnecting from the bus (and is
re-enumerated) unless opened (and kept open, should an input event
occur).
Note that while the device can be run-time suspended, the autosuspend
timeout must be high enough to allow the device to be polled at least
once before being suspended. Specifically, using autosuspend_delay_ms=0
will still cause the device to disconnect on input events.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add quirk to make sure that a device is always polled for input events
even if it hasn't been opened.
This is needed for devices that disconnects from the bus unless the
interrupt endpoint has been polled at least once or when not responding
to an input event (e.g. after having shut down X).
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch changes the way usbhid carries out Clear-Halt and reset.
Currently, after a Clear-Halt on the interrupt-IN endpoint, the driver
immediately restarts the interrupt URB, even if the Clear-Halt failed.
This doesn't work out well when the reason for the failure was that
the device was disconnected (when a low- or full-speed device is
connected through a hub to an EHCI controller, transfer errors caused
by disconnection are reported as stalls by the hub). Instead now the
driver will attempt a reset after a failed Clear-Halt.
The way resets are carried out is also changed. Now the driver will
call usb_queue_reset_device() instead of calling usb_reset_device()
directly. This avoids a deadlock that would arise when a device is
unplugged: The hid_reset() routine runs as a workqueue item, a reset
attempt after the device has been unplugged will fail, failure will
cause usbhid to be unbound, and the disconnect routine will try to do
cancel_work_sync(). The usb_queue_reset_device() implementation is
carefully written to handle scenarios like this one properly.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
I am using a USB keyborad that give me "usb_submit_urb(ctrl) failed: -1" error
when I plugin it. and I need to wait for 10s for this device to be ready.
By adding this quirks, the usb keyborad is usable right after plugin
Signed-off-by: Wangzhao Cai <microcaicai@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This driver adds support for USB controlled led panels that exists in
MSI GT683R laptop
Signed-off-by: Janne Kanniainen <janne.kanniainen@gmail.com>
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
These device needs to be added to the quirks list with HID_QUIRK_NOGET,
otherwise they will reset upon receiving the get input report requests.
Signed-off-by: John Sung <penmount.touch@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The quirks_param array is located in the BSS, no need to explicitly
initialize it with NULL.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The device which identifies itself as a "USB Keykoard" (no typo) with VID:PID
1a2c:0023 does not seem to be handling the reports initialization very well.
This results in a "usb_submit_urb(ctrl) failed: -1" message from the kernel
when connected, and a delay before its initialization. This patch adds the
quirk for this device, which causes the delay to disappear.
[jkosina@suse.cz: remove superfluous comment and fix ordering]
Signed-off-by: Daniel Kamil Kozar <dkk089@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This touchpad seriously dislikes init reports, not only timeing out, but
also refusing to work after this.
Cc: stable@vger.kernel.org
Reported-and-tested-by: Vincent Fortier <th0ma7@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Nobody calls hid_output_raw_report anymore, and nobody should.
We can now remove the various implementation in the different
transport drivers and the declarations.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
hid_out_raw_report is going to be obsoleted as it is not part of the
unified HID low level transport documentation
(Documentation/hid/hid-transport.txt)
To do so, we need to introduce two new quirks:
* HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP: this quirks prevents the
transport driver to use the interrupt channel to send output report
(and thus force to use HID_REQ_SET_REPORT command)
* HID_QUIRK_SKIP_OUTPUT_REPORT_ID: this one forces usbhid to not
include the report ID in the buffer it sends to the device through
HID_REQ_SET_REPORT in case of an output report
This also fixes a regression introduced in commit 3a75b24949
(HID: hidraw: replace hid_output_raw_report() calls by appropriates ones).
The hidraw API was not able to communicate with the PS3 SixAxis
controllers in USB mode.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Antonio Ospite <ao2@ao2.it>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
If there is no urbout when sending a output report, ENOSYS (Function
not implemented) is a better error than EIO (I/O error).
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
dev->hid_get_raw_report(X) and hid_hw_raw_request(X, HID_REQ_GET_REPORT)
are strictly equivalent. Switch the hid subsystem to the hid_hw notation
and remove the field .hid_get_raw_report in struct hid_device.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Well, no use to keep twice the same code.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add raw_request, set_raw_report and output_report transport-driver functions to
the USB HID driver.
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Acked-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add Synaptics HD touchscreen(06cb:1ac3) to no init report quirk
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add Synaptics HD touchscreen(06cb:0ac3) to no init report quirk.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
USB_VENDOR_ID_SIS and USB_VENDOR_ID_SIS2_TOUCH are identical,
so refine the code and merge the quirks.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
It looks like this typo was introduced by a mistake in a copy-and-paste in
commit ddbe324919.
Signed-off-by: Adam Cozzette <acozzette@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
BugLink: http://bugs.launchpad.net/bugs/1180881
This device needs to be added to the quirks list with HID_QUIRK_NO_INIT_REPORTS,
otherwise it causes 10 seconds timeout during report initialization.
[12431.828467] hid-multitouch 0003:0457:1013.0475: usb_submit_urb(ctrl) failed: -1
[12431.828507] hid-multitouch 0003:0457:1013.0475: timeout initializing reports
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
BugLink: http://bugs.launchpad.net/bugs/1180881
Synaptics large touchscreen doesn't support some of the report request
while initializing. The unspoorted request will make the device unreachable,
and will lead to the following usb_submit_urb() function call timeout.
So, add the IDs into HID_QUIRK_NO_INIT_REPORTS quirk.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The DuoSense touchscreen device causes a 10 second timeout. This fix
removes the delay.
Signed-off-by: Vasily Titskiy <qehgt0@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some multitouch screens do not like to be polled for input reports.
However, the Win8 spec says that all touches should be sent during
each report, making the initialization of reports unnecessary.
The Win7 spec is less precise, so do not use this for those devices.
Add the quirk HID_QUIRK_NO_INIT_INPUT_REPORTS so that we do not have to
introduce a quirk for each problematic device. This quirk makes the driver
behave the same way the Win 8 does. It actually retrieves the features,
but not the inputs.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Tested-by: Srinivas Pandruvada<srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID core provides the same functionality as we do, so drop the custom
hidinput_input_event() handler.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Report fields can be updated from HID drivers unlocked via
hid_set_field(). It is protected by input_lock in HID core so only a
single input event is handled at a time. USBHID can thus update the field
unlocked and doesn't conflict with any HID vendor/device drivers. Note,
many HID drivers make heavy use of hid_set_field() in that way.
But usbhid also schedules a work to gather multiple LED changes in a
single report. Hence, we used to lock the LED field update so the work can
read a consistent state. However, hid_set_field() only writes a single
integer field, which is guaranteed to be allocated all the time. So the
worst possible race-condition is a garbage read on the LED field.
Therefore, there is no need to protect the update. In fact, the only thing
that is prevented by locking hid_set_field(), is an LED update while the
scheduled work currently writes an older LED update out. However, this
means, a new work is scheduled directly when the old one is done writing
the new state to the device. So we actually _win_ by not protecting the
write and allowing the write to be combined with the current write. A new
worker is still scheduled, but will not write any new state. So the LED
will not blink unnecessarily on the device.
Assume we have the LED set to 0. Two request come in which enable the LED
and immediately disable it. The current situation with two CPUs would be:
usb_hidinput_input_event() | hid_led()
---------------------------------+----------------------------------
spin_lock(&usbhid->lock);
hid_set_field(1);
spin_unlock(&usbhid->lock);
schedule_work(...);
spin_lock(&usbhid->lock);
__usbhid_submit_report(..1..);
spin_unlock(&usbhid->lock);
spin_lock(&usbhid->lock);
hid_set_field(0);
spin_unlock(&usbhid->lock);
schedule_work(...);
spin_lock(&usbhid->lock);
__usbhid_submit_report(..0..);
spin_unlock(&usbhid->lock);
With the locking removed, we _might_ end up with (look at the changed
__usbhid_submit_report() parameters in the first try!):
usb_hidinput_input_event() | hid_led()
---------------------------------+----------------------------------
hid_set_field(1);
schedule_work(...);
spin_lock(&usbhid->lock);
hid_set_field(0);
schedule_work(...);
__usbhid_submit_report(..0..);
spin_unlock(&usbhid->lock);
... next work ...
spin_lock(&usbhid->lock);
__usbhid_submit_report(..0..);
spin_unlock(&usbhid->lock);
As one can see, we no longer send the "LED ON" signal as it is disabled
immediately afterwards and the following "LED OFF" request overwrites the
pending "LED ON".
It is important to note that hid_set_field() is not atomic, so we might
also end up with any other value. But that doesn't matter either as we
_always_ schedule the next work with a correct value and schedule_work()
acts as memory barrier, anyways. So in the worst case, we run
__usbhid_submit_report(..<garbage>..) in the first case and the following
__usbhid_submit_report() will write the correct value. But LED states are
booleans so any garbage will be converted to either 0 or 1 and the remote
device will never see invalid requests.
Why all this? It avoids any custom locking around hid_set_field() in
usbhid and finally allows us to provide a generic hidinput_input_event()
handler for all HID transport drivers.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Nikolai Kondrashov
Yuta Kobayashi
Scott Bauer
Jiri Kosina
Trent Lloyd
Nazar Mokrynskyi
Alan Stern
Daniel Bristot de Oliveira
Stafford Horne
Benjamin Tissoires
Linus Torvalds
Geliang Tang
Adrien Vergé
Ioan-Adrian Ratiu
Oliver Neukum
Jimmy Berry
Oliver Schmitt
Donavan Lance
Don Zickus
Stephen Just
Oliver Neukum
Reyad Attiyat
Raimund Roth
Herton R. Krzesinski
Laura Abbott
Sean Young
Raphael Assenat
Jim Keir
oliver@neukum.org
Milan Plzik
Michal Marek
Alan Wu
Giedrius Statkevičius
Mathieu Magnaudet
Adel Gadllah
Johan Hovold
Wen-chien Jesse Sung
Wangzhao Cai
Janne Kanniainen
John Sung
Mathias Krause
Hans de Goede
Frank Praznik
Yufeng Shen
Emanuel Krenz
AceLan Kao
Adam Cozzette
Forest Bond
Vasily Titskiy
David Herrmann