- 22 7月, 2013 2 次提交
-
-
由 Nestor Lopez Casado 提交于
Set querying_devices flag to true when we start the enumeration process. This was missing from the original patch. It never produced undesirable effects as it is highly improbable to have a second enumeration triggered while a first one was still in progress. Signed-off-by: NNestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Nestor Lopez Casado 提交于
This reverts commit 8af6c088. This patch re-adds the workaround introduced by 59626408 which was reverted by 8af6c088. The original patch 596264 was needed to overcome a situation where the hid-core would drop incoming reports while probe() was being executed. This issue was solved by c849a614 which added hid_device_io_start() and hid_device_io_stop() that enable a specific hid driver to opt-in for input reports while its probe() is being executed. Commit a9dd22b7 modified hid-logitech-dj so as to use the functionality added to hid-core. Having done that, workaround 596264 was no longer necessary and was reverted by 8af6c088. We now encounter a different problem that ends up 'again' thwarting the Unifying receiver enumeration. The problem is time and usb controller dependent. Ocasionally the reports sent to the usb receiver to start the paired devices enumeration fail with -EPIPE and the receiver never gets to enumerate the paired devices. With dcd9006b the problem was "hidden" as the call to the usb driver became asynchronous and none was catching the error from the failing URB. As the root cause for this failing SET_REPORT is not understood yet, -possibly a race on the usb controller drivers or a problem with the Unifying receiver- reintroducing this workaround solves the problem. Overall what this workaround does is: If an input report from an unknown device is received, then a (re)enumeration is performed. related bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1194649Signed-off-by: NNestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 07 3月, 2013 1 次提交
-
-
由 Benjamin Tissoires 提交于
hid_output_raw_report() makes a direct call to usb_control_msg(). However, some USB3 boards have shown that the usb device is not ready during the .probe(). This blocks the entire usb device, and the paired mice, keyboards are not functional. The dmesg output is the following: [ 11.912287] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2 [ 11.912537] logitech-djreceiver 0003:046D:C52B.0003: logi_dj_probe:logi_dj_recv_query_paired_devices error:-32 [ 11.912636] logitech-djreceiver: probe of 0003:046D:C52B.0003 failed with error -32 Relying on the scheduled call to usbhid_submit_report() fixes the problem. related bugs: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039143 https://bugzilla.redhat.com/show_bug.cgi?id=840391 https://bugzilla.kernel.org/show_bug.cgi?id=49781Reported-and-tested-by: NBob Bowles <bobjohnbowles@gmail.com> Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 01 3月, 2013 2 次提交
-
-
由 Andrew de los Reyes 提交于
This reverts commit 59626408. The reverted commit was a workaround needed when drivers became unable to communicate with devices during probe(). Now that such communication is possible, the workaround is not needed. Signed-off-by: NAndrew de los Reyes <adlr@chromium.org> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Andrew de los Reyes 提交于
Historically, logitech-dj communicated with the device during probe() to query the list of devices attached. Later, a change was introduced to hid-core that prevented incoming packets for a device during probe(), as many drivers are unable to handle such input. That change broke the device enumeration in logitech-dj, so commit 59626408 was introduced to workaround that by waiting for normal input before enumerating devices. Now that drivers can opt-in to receive input during probe, this patch changes logitech-dj to do that, so that it can successfully complete enumeration of devices during probe(). Signed-off-by: NAndrew de los Reyes <adlr@chromium.org> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 25 2月, 2013 1 次提交
-
-
由 Benjamin Tissoires 提交于
This allows the hid drivers to be independent from the transport layer. The patch was constructed by replacing all occurences of usbhid_submit_report() by its hid_hw_request() counterpart. Then, drivers not requiring USB_HID anymore have their USB_HID dependency cleaned in the Kconfig file. Finally, few drivers still depends on USB_HID. Many of them are requiring the io wait callback. They are found in the next patch. Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> For the sensor-hub part: Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 22 9月, 2012 1 次提交
-
-
由 Nestor Lopez Casado 提交于
This patch fixes an issue introduced after commit 4ea54542 ("HID: Fix race condition between driver core and ll-driver"). After that commit, hid-core discards any incoming packet that arrives while hid driver's probe function is being executed. This broke the enumeration process of hid-logitech-dj, that must receive control packets in-band with the mouse and keyboard packets. Discarding mouse or keyboard data at the very begining is usually fine, but it is not the case for control packets. This patch forces a re-enumeration of the paired devices when a packet arrives that comes from an unknown device. Based on a patch originally written by Benjamin Tissoires. Cc: stable@vger.kernel.org # v3.2+ Signed-off-by: NNestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 06 9月, 2012 1 次提交
-
-
由 Alan Cox 提交于
Allocate a structure not a pointer to it ! Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 03 6月, 2012 1 次提交
-
-
由 Marc Dionne 提交于
On a system with a logitech wireless keyboard/mouse and DMA-API debugging enabled, this warning appears at boot: kernel: WARNING: at lib/dma-debug.c:929 check_for_stack.part.12+0x70/0xa7() kernel: Hardware name: MS-7593 kernel: uhci_hcd 0000:00:1d.1: DMA-API: device driver maps memory fromstack [addr=ffff8801b0079c29] Make logi_dj_recv_query_paired_devices and logi_dj_recv_switch_to_dj_mode use a structure allocated with kzalloc rather than a stack based one. Signed-off-by: NMarc Dionne <marc.c.dionne@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 11 5月, 2012 1 次提交
-
-
由 Jonathan Nieder 提交于
On big-endian systems (e.g., Apple PowerBook), trying to use a logitech wireless mouse with the Logitech Unifying Receiver does not work with v3.2 and later kernels. The device doesn't show up in /dev/input. Older kernels work fine. That is because the new hid-logitech-dj driver claims the device. The device arrival notification appears: 20 00 41 02 00 00 00 00 00 00 00 00 00 00 00 and we read the report_types bitfield (02 00 00 00) to find out what kind of device it is. Unfortunately the driver only reads the first 8 bits and treats that value as a 32-bit little-endian number, so on a powerpc the report type seems to be 0x02000000 and is not recognized. Even on little-endian machines, connecting a media center remote control (report type 00 01 00 00) with this driver loaded would presumably fail for the same reason. Fix both problems by using get_unaligned_le32() to read all four bytes, which is a little clearer anyway. After this change, the wireless mouse works on Hugo's PowerBook again. Based on a patch by Nestor Lopez Casado. Addresses http://bugs.debian.org/671292Reported-by: NHugo Osvaldo Barrera <hugo@osvaldobarrera.com.ar> Inspired-by: NNestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NNestor Lopez Casado <nlopezcasad@logitech.com> Cc: <stable@vger.kernel.org> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 01 5月, 2012 1 次提交
-
-
由 Henrik Rydberg 提交于
The current code allows several consecutive calls to hid_parse_report(), which may have happened to work before, but would cause a memory leak and generally be incorrect. This patch collects all the reports before sending them once. Cc: Nestor Lopez Casado <nlopezcasad@logitech.com> Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com Signed-off-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 02 2月, 2012 1 次提交
-
-
由 Nestor Lopez Casado 提交于
The user can only experience the bug if she pairs 6 devices to a Unifying receiver. The sixth paired device would not work. The value changed is actually a bitmask that enables reporting from each paired device. As the sixth bit was not set, the sixth device reports are ignored by the receiver and never get to the driver. Signed-off-by: NNestor Lopez Casado <nlopezcasad@logitech.com> drivers/hid/hid-logitech-dj.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 20 9月, 2011 1 次提交
-
-
由 Nestor Lopez Casado 提交于
There is a bug where a device with index 6 would write out of bounds in the array of paired devices. This patch fixes that problem. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com> Reviewed-by: NOlivier Gay <ogay@logitech.com> Signed-off-by: NNestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 15 9月, 2011 1 次提交
-
-
由 Nestor Lopez Casado 提交于
With this driver, all the devices paired to a single Unifying receiver are exposed to user processes in separated /input/dev nodes. Keyboards with different layouts can be treated differently, Multiplayer games on single PC (like home theater PC) can differentiate input coming from different kbds paired to the same receiver. Up to now, when Logitech Unifying receivers are connected to a Linux based system, a single keyboard and a single mouse are presented to the HID Layer, even if the Unifying receiver can pair up to six compatible devices. The Unifying receiver by default multiplexes all incoming events (from multiple keyboards/mice) into these two. Signed-off-by: NNestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-