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>
usbhid_set_leds() is only used inside of usbhid/hid-core.c so no need to export it. 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>
implement() is setting bytes in LE data stream. In case the data is not aligned to 64bits, it reads past the allocated buffer. It doesn't really change any value there (it's properly bitmasked), but in case that this read past the boundary hits a page boundary, pagefault happens when accessing 64bits of 'x' in implement(), and kernel oopses. This happens much more often when numbered reports are in use, as the initial 8bit skip in the buffer makes the whole process work on values which are not aligned to 64bits. This problem dates back to attempts in 2005 and 2006 to make implement() and extract() as generic as possible, and even back then the problem was realized by Adam Kroperlin, but falsely assumed to be impossible to cause any harm: http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html I have made several attempts at fixing it "on the spot" directly in implement(), but the results were horrible; the special casing for processing last 64bit chunk and switching to different math makes it unreadable mess. I therefore took a path to allocate a few bytes more which will never make it into final report, but are there as a cushion for all the 64bit math operations happening in implement() and extract(). All callers of hid_output_report() are converted at the same time to allocate the buffer by newly introduced hid_alloc_report_buf() helper. Bruno noticed that the whole raw_size test can be dropped as well, as hid_alloc_report_buf() makes sure that the buffer is always of a proper size. Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull HID updates from Jiri Kosina: - hid driver transport cleanup, finalizing the long-desired decoupling of core from transport layers, by Benjamin Tissoires and Henrik Rydberg - support for hybrid finger/pen multitouch HID devices, by Benjamin Tissoires - fix for long-standing issue in Logitech unifying driver sometimes not inializing properly due to device specifics, by Andrew de los Reyes - Wii remote driver updates to support 2nd generation of devices, by David Herrmann - support for Apple IR remote - roccat driver now supports new devices (Roccat Kone Pure, IskuFX), by Stefan Achatz - debugfs locking fixes in hid debug interface, by Jiri Kosina * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (43 commits) HID: protect hid_debug_list HID: debug: break out hid_dump_report() into hid-debug HID: Add PID for Japanese version of NE4K keyboard HID: hid-lg4ff add support for new version of DFGT wheel HID: icade: u16 which never < 0 HID: clarify Magic Mouse Kconfig description HID: appleir: add support for Apple ir devices HID: roccat: added media key support for Kone HID: hid-lenovo-tpkbd: remove doubled hid_get_drvdata HID: i2c-hid: fix length for set/get report in i2c hid HID: wiimote: parse reduced status reports HID: wiimote: add 2nd generation Wii Remote IDs HID: wiimote: use unique battery names HID: hidraw: warn if userspace headers are outdated HID: multitouch: force BTN_STYLUS for pen devices HID: multitouch: append " Pen" to the name of the stylus input HID: multitouch: add handling for pen in dual-sensors device HID: multitouch: change touch sensor detection in mt_input_configured() HID: multitouch: do not map usage from non used reports HID: multitouch: breaks out touch handling in specific functions ...