#
21f28a7e |
|
03-Apr-2024 |
Yaraslau Furman <yaro330@gmail.com> |
HID: logitech-dj: allow mice to use all types of reports You can bind whatever action you want to the mouse's reprogrammable buttons using Windows application. Allow Linux to receive multimedia keycodes. Fixes: 3ed224e273ac ("HID: logitech-dj: Fix 064d:c52f receiver support") Signed-off-by: Yaraslau Furman <yaro330@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
#
5b4ffb17 |
|
21-Nov-2023 |
Jiri Kosina <jkosina@suse.cz> |
Revert "HID: logitech-dj: Add support for a new lightspeed receiver iteration" This reverts commit 9d1bd9346241cd6963b58da7ffb7ed303285f684. Multiple people reported misbehaving devices and reverting this commit fixes the problem for them. As soon as the original commit author starts reacting again, we can try to figure out why he hasn't seen the issues (mismatching report descriptors?), but for the time being, fix for 6.7 by reverting. Link: https://bugzilla.kernel.org/show_bug.cgi?id=218172 Link: https://bugzilla.kernel.org/show_bug.cgi?id=218094 Cc: <stable@vger.kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
6f20d326 |
|
13-Jun-2023 |
Nikita Zhandarovich <n.zhandarovich@fintech.ru> |
HID: logitech-dj: Fix error handling in logi_dj_recv_switch_to_dj_mode() Presently, if a call to logi_dj_recv_send_report() fails, we do not learn about the error until after sending short HID_OUTPUT_REPORT with hid_hw_raw_request(). To handle this somewhat unlikely issue, return on error in logi_dj_recv_send_report() (minding ugly sleep workaround) and take into account the result of hid_hw_raw_request(). Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: 6a9ddc897883 ("HID: logitech-dj: enable notifications on connect/disconnect") Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> Link: https://lore.kernel.org/r/20230613101635.77820-1-n.zhandarovich@fintech.ru Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
9d1bd934 |
|
16-Jul-2023 |
Mavroudis Chatzilazaridis <mavchatz@protonmail.com> |
HID: logitech-dj: Add support for a new lightspeed receiver iteration The lightspeed receiver for the Pro X Superlight uses 13 byte mouse reports without a report id. The workaround for such cases has been adjusted to handle these larger packets. The device now reports the status of its battery in wireless mode and libratbag now recognizes the device and it can be configured with Piper. https://github.com/libratbag/libratbag/pull/1122 Co-developed-by: Filipe Laíns <lains@riseup.net> Signed-off-by: Filipe Laíns <lains@riseup.net> Signed-off-by: Mavroudis Chatzilazaridis <mavchatz@protonmail.com> Reviewed-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
662eee8d |
|
29-Jan-2023 |
Thomas Weißschuh <linux@weissschuh.net> |
HID: logitech-dj: Constify lowlevel HID driver Since commit 52d225346904 ("HID: Make lowlevel driver structs const") the lowlevel HID drivers are only exposed as const. Take advantage of this to constify the underlying structure, too. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230130-hid-const-ll-driver-v1-3-3fc282b3b1d0@weissschuh.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
25666e8c |
|
26-Jan-2022 |
Lucas Zampieri <lzampier@redhat.com> |
HID: logitech-dj: add new lightspeed receiver id As of logitech lightspeed receiver fw version 04.02.B0009, HIDPP_PARAM_DEVICE_INFO is being reported as 0x11. With patch "HID: logitech-dj: add support for the new lightspeed receiver iteration", the mouse starts to error out with: logitech-djreceiver: unusable device of type UNKNOWN (0x011) connected on slot 1 and becomes unusable. This has been noticed on a Logitech G Pro X Superlight fw MPM 25.01.B0018. Signed-off-by: Lucas Zampieri <lzampier@redhat.com> Acked-by: Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
f83baa0c |
|
01-Dec-2021 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
HID: add hid_is_usb() function to make it simpler for USB detection A number of HID drivers already call hid_is_using_ll_driver() but only for the detection of if this is a USB device or not. Make this more obvious by creating hid_is_usb() and calling the function that way. Also converts the existing hid_is_using_ll_driver() functions to use the new call. Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-input@vger.kernel.org Cc: stable@vger.kernel.org Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211201183503.2373082-1-gregkh@linuxfoundation.org
|
#
622d97cf |
|
29-May-2021 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: Implement may_wakeup ll-driver callback Without a ll-driver callback hid_hw_may_wakeup() will return: device_may_wakeup(hdev->dev.parent), but for the hid devices instantiated by logitech-dj for devices behind the receiver the logitech-dj hid(pp)-device is the parent. Add a logi_dj_ll_may_wakeup() callback which calls hid_hw_may_wakeup() on the logitech-dj hid(pp) parent-hid-device. 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>
|
#
7383354a |
|
04-Apr-2021 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj/hidpp: Add info/warn/err messages about 27 MHz keyboard encryption By default 27 MHz Logitech keyboards send the keypresses to the receiver in plain text. Logitech's Windows "Keyboard and Mouse settings" tool allows configuring encryption for the keyboard wireless link. Now there also is a Linux tool for setting this up: https://gitlab.freedesktop.org/jwrdegoede/logitech-27mhz-keyboard-encryption-setup Once a keyboard is paired in encrypted mode, it will no longer work with any receiver other then the receiver it was paired with. If a user accidentally tries to pair another keyboard with the receiver with which a keyboard has been paired in encrypted mode, then the receiver looses the encryption key and the originally paired keyboard will no longer work with either that receiver, or another receiver until the keyboard's encryption key is rewritten by another encrypted mode pairing using the tool. Or until it is reset by following a special reset procedure. This commit adds 3 new log messages related to 27 MHz keyboard link encryption to the Logitech dj / hidpp drivers: 1. An info level message when keyboard encryption is being used 2. A warning message when keyboard encryption is not used 3. An error message when the encryption key has been lost and the keyboard will not work because of this Messages 2. and 3. contain a link to the userspace tool to setup the encryption. The linked page also contains instructions to clear the key (without needing the tool) to help a user recover from the keyboard not working in case 3. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
434f7709 |
|
04-Feb-2021 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: Handle newer quad/bt2.0 receivers in HID proxy mode The Dinovo Edge and Dinovo Mini keyboards with builtin touchpad come with a different version of the quad/bt2.0 combo receivers shipped with the MX5000 and MX5500 keyboards. These receivers are compatible with one another, e.g. the Dinovo Edge keyboard can be paired with the MX5000 receiver. Like the MX5x00 receivers in HID proxy mode these receivers present themselves as a hub with multiple USB-HID devices, one for the keyboard and one for the mouse. Where they differ is that the mouse USB-device has 2 input reports for reporting mice events. It has the exact same INPUT(2) report as the MX5x00 receivers, but it also has a second INPUT(5) mouse report which is different; and when the Dinovo receivers are paired with the Dinovo keyboards the second INPUT(5) mouse report is actually used for events on the builtin touchpad. Add support for handling the Dinovo quad/bluetooth-2.0 combo receivers in HID proxy mode to logitech-dj, like we already do for the similar MX5000 and MX5500 receivers. This adds battery monitoring functionality (through logitech-hidpp) and fixes the Phone (Fn + F1) and "[A]" - "[D]" (Fn + F9 - F12) hotkeys not working on the Dinovo Edge. Note these receivers present themselves as a hub with 2 separate USB devices for the keyboard and mouse; and the logitech-dj code needs to bind to both devices (just as with the MX5x00 receivers). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
751cb651 |
|
04-Feb-2021 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: Use hid-ids.h defines for USB device-ids for all supported devices The logitech-dj code already uses hid-ids.h defines for almost all devices it supports. Lets be consistent: add and use hid-ids.h defines for the G700, MX5000 and MX5500 receivers too. Also add / update some comments to make the comment style in the hid_device_id table consistent too. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
fab3a956 |
|
23-Jan-2021 |
Filipe Laíns <lains@riseup.net> |
HID: logitech-dj: add support for the new lightspeed connection iteration This new connection type is the new iteration of the Lightspeed connection and will probably be used in some of the newer gaming devices. It is currently use in the G Pro X Superlight. This patch should be backported to older versions, as currently the driver will panic when seing the unsupported connection. This isn't an issue when using the receiver that came with the device, as Logitech has been using different PIDs when they change the connection type, but is an issue when using a generic receiver (well, generic Lightspeed receiver), which is the case of the one in the Powerplay mat. Currently, the only generic Ligthspeed receiver we support, and the only one that exists AFAIK, is ther Powerplay. As it stands, the driver will panic when seeing a G Pro X Superlight connected to the Powerplay receiver and won't send any input events to userspace! The kernel will warn about this so the issue should be easy to identify, but it is still very worrying how hard it will fail :( [915977.398471] logitech-djreceiver 0003:046D:C53A.0107: unusable device of type UNKNOWN (0x0f) connected on slot 1 Signed-off-by: Filipe Laíns <lains@riseup.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
ef07c116 |
|
05-Feb-2021 |
Filipe Laíns <lains@riseup.net> |
HID: logitech-dj: add support for keyboard events in eQUAD step 4 Gaming In e400071a805d6229223a98899e9da8c6233704a1 I added support for the receiver that comes with the G602 device, but unfortunately I screwed up during testing and it seems the keyboard events were actually not being sent to userspace. This resulted in keyboard events being broken in userspace, please backport the fix. The receiver uses the normal 0x01 Logitech keyboard report descriptor, as expected, so it is just a matter of flagging it as supported. Reported in https://github.com/libratbag/libratbag/issues/1124 Fixes: e400071a805d6 ("HID: logitech-dj: add the G602 receiver") Cc: <stable@vger.kernel.org> Signed-off-by: Filipe Laíns <lains@riseup.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
e400071a |
|
04-Jan-2021 |
Filipe Laíns <lains@archlinux.org> |
HID: logitech-dj: add the G602 receiver Tested. The device gets correctly exported to userspace and I can see mouse and keyboard events. Signed-off-by: Filipe Laíns <lains@archlinux.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
b4c00e79 |
|
14-Nov-2020 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: Fix Dinovo Mini when paired with a MX5x00 receiver Some users are pairing the Dinovo keyboards with the MX5000 or MX5500 receivers, instead of with the Dinovo receivers. The receivers are mostly the same (and the air protocol obviously is compatible) but currently the Dinovo receivers are handled by hid-lg.c while the MX5x00 receivers are handled by logitech-dj.c. When using a Dinovo keyboard, with its builtin touchpad, through logitech-dj.c then the touchpad stops working because when asking the receiver for paired devices, we get only 1 paired device with a device_type of REPORT_TYPE_KEYBOARD. And since we don't see a paired mouse, we have nowhere to send mouse-events to, so we drop them. Extend the existing fix for the Dinovo Edge for this to also cover the Dinovo Mini keyboard and also add a mapping to logitech-hidpp for the Media key on the Dinovo Mini, so that that keeps working too. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1811424 Fixes: f2113c3020ef ("HID: logitech-dj: add support for Logitech Bluetooth Mini-Receiver") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
eec231e0 |
|
14-Nov-2020 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: Fix an error in mse_bluetooth_descriptor Fix an error in the mouse / INPUT(2) descriptor used for quad/bt2.0 combo receivers. Replace INPUT with INPUT (Data,Var,Abs) for the field for the 4 extra buttons which share their report-byte with the low-res hwheel. This is likely a copy and paste error. I've verified that the new 0x81, 0x02 value matches both the mouse descriptor for the currently supported MX5000 / MX5500 receivers, as well as the INPUT(2) mouse descriptors for the Dinovo receivers for which support is being worked on. Cc: stable@vger.kernel.org Fixes: f2113c3020ef ("HID: logitech-dj: add support for Logitech Bluetooth Mini-Receiver") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
ee5e5841 |
|
02-Nov-2020 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: Handle quad/bluetooth keyboards with a builtin trackpad Some quad/bluetooth keyboards, such as the Dinovo Edge (Y-RAY81) have a builtin touchpad. In this case when asking the receiver for paired devices, we get only 1 paired device with a device_type of REPORT_TYPE_KEYBOARD. This means that we do not instantiate a second dj_hiddev for the mouse (as we normally would) and thus there is no place for us to forward the mouse input reports to, causing the touchpad part of the keyboard to not work. There is no way for us to detect these keyboards, so this commit adds an array with device-ids for such keyboards and when a keyboard is on this list it adds STD_MOUSE to the reports_supported bitmap for the dj_hiddev created for the keyboard fixing the touchpad not working. Using a list of device-ids for this is not ideal, but there are only very few such keyboards so this should be fine. Besides the Dinovo Edge, other known wireless Logitech keyboards with a builtin touchpad are: * Dinovo Mini (TODO add its device-id to the list) * K400 (uses a unifying receiver so is not affected) * K600 (uses a unifying receiver so is not affected) Cc: stable@vger.kernel.org BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1811424 Fixes: f2113c3020ef ("HID: logitech-dj: add support for Logitech Bluetooth Mini-Receiver") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
53ed4cf6 |
|
25-May-2020 |
Chris Packham <chris.packham@alliedtelesis.co.nz> |
HID: logitech-dj: Fix spelling in comment Change 'unhandeled' to 'unhandled'. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
df561f66 |
|
23-Aug-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
|
#
7f02bb62 |
|
04-Jul-2020 |
Mazin Rezk <mnrzk@protonmail.com> |
HID: logitech: Use HIDPP_RECEIVER_INDEX instead of 0xff Some parts of hid-logitech-dj explicitly referred to 0xff for the receiver index. This patch changes those references to the HIDPP_RECEIVER_INDEX definition. Signed-off-by: Mazin Rezk <mnrzk@protonmail.com> Reviewed-by: Filipe Laíns <lains@archlinux.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
c08ce255 |
|
12-Jan-2020 |
Filipe Laíns <lains@archlinux.org> |
HID: logitech: drop outdated references to unifying receivers The hid-logitech-{dj,hidpp} were originally developed for unifying receivers but since then they have evolved and now support other types of receivers and devices. This patch adjusts the original descriptions with this in mind. Signed-off-by: Filipe Laíns <lains@archlinux.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
8c9d734c |
|
15-Jan-2020 |
Filipe Laíns <lains@archlinux.org> |
HID: logitech-dj: add support for the static device in the Powerplay mat/receiver The Logitech G Powerplay has a lightspeed receiver with a static HID++ device with ID 7 attached to it to. It is used to configure the led on the mat. For this reason I increased the max number of devices. Signed-off-by: Filipe Laíns <lains@archlinux.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
630dd6ea |
|
13-Jan-2020 |
Filipe Laíns <lains@archlinux.org> |
HID: logitech-dj: add debug msg when exporting a HID++ report descriptors When exporting all other types of report descriptors we print a debug message. Not doing so for HID++ descriptors makes unaware users think that no HID++ descriptor was exported. Signed-off-by: Filipe Laíns <lains@archlinux.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
8ccff284 |
|
25-Aug-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: Fix crash when initial logi_dj_recv_query_paired_devices fails Before this commit dj_probe would exit with an error if the initial logi_dj_recv_query_paired_devices fails. The initial call may fail when the receiver is connected through a kvm and the focus is away. When the call fails this causes 2 problems: 1) dj_probe calls logi_dj_recv_query_paired_devices after calling hid_device_io_start() so a HID report may have been received in between and our delayedwork_callback may be running. It seems that the initial logi_dj_recv_query_paired_devices failure happening with some KVMs triggers this exact scenario, causing the work-queue to run on free-ed memory, leading to: BUG: unable to handle page fault for address: 0000000000001e88 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 3 PID: 257 Comm: kworker/3:3 Tainted: G OE 5.3.0-rc5+ #100 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B150M Pro4S/D3, BIOS P7.10 12/06/2016 Workqueue: events 0xffffffffc02ba200 RIP: 0010:0xffffffffc02ba1bd Code: e8 e8 13 00 d8 48 89 c5 48 85 c0 74 4c 48 8b 7b 10 48 89 ea b9 07 00 00 00 41 b9 09 00 00 00 41 b8 01 00 00 00 be 10 00 00 00 <48> 8b 87 88 1e 00 00 48 8b 40 40 e8 b3 6b b4 d8 48 89 ef 41 89 c4 RSP: 0018:ffffb760c046bdb8 EFLAGS: 00010286 RAX: ffff935038ea4550 RBX: ffff935046778000 RCX: 0000000000000007 RDX: ffff935038ea4550 RSI: 0000000000000010 RDI: 0000000000000000 RBP: ffff935038ea4550 R08: 0000000000000001 R09: 0000000000000009 R10: 000000000000e011 R11: 0000000000000001 R12: ffff9350467780e8 R13: ffff935046778000 R14: 0000000000000000 R15: ffff935046778070 FS: 0000000000000000(0000) GS:ffff935054e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001e88 CR3: 000000075a612002 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: 0xffffffffc02ba2f7 ? process_one_work+0x1b1/0x560 process_one_work+0x234/0x560 worker_thread+0x50/0x3b0 kthread+0x10a/0x140 ? process_one_work+0x560/0x560 ? kthread_park+0x80/0x80 ret_from_fork+0x3a/0x50 Modules linked in: vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) bnep vfat fat btusb btrtl btbcm btintel bluetooth intel_rapl_msr ecdh_generic rfkill ecc snd_usb_audio snd_usbmidi_lib intel_rapl_common snd_rawmidi mc x86_pkg_temp_thermal intel_powerclamp coretemp iTCO_wdt iTCO_vendor_support mei_wdt mei_hdcp ppdev kvm_intel kvm irqbypass crct10dif_pclmul crc32_generic crc32_pclmul snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio ghash_clmulni_intel intel_cstate snd_hda_intel snd_hda_codec intel_uncore snd_hda_core snd_hwdep intel_rapl_perf snd_seq snd_seq_device snd_pcm snd_timer intel_wmi_thunderbolt snd e1000e soundcore mxm_wmi i2c_i801 bfq mei_me mei intel_pch_thermal parport_pc parport acpi_pad binfmt_misc hid_lg_g15(E) hid_logitech_dj(E) i915 crc32c_intel i2c_algo_bit drm_kms_helper nvme nvme_core drm wmi video uas usb_storage i2c_dev CR2: 0000000000001e88 ---[ end trace 1d3f8afdcfcbd842 ]--- 2) Even if we were to fix 1. by making sure the work is stopped before failing probe, failing probe is the wrong thing to do, we have logi_dj_recv_queue_unknown_work to deal with the initial logi_dj_recv_query_paired_devices failure. Rather then error-ing out of the probe, causing the receiver to not work at all we should rely on this, so that the attached devices will get properly enumerated once the KVM focus is switched back. Cc: stable@vger.kernel.org Fixes: 74808f9115ce ("HID: logitech-dj: add support for non unifying receivers") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
5722f338 |
|
30-Jul-2019 |
Filipe Laíns <lains@archlinux.org> |
hid-logitech-dj: add the new Lightspeed receiver This patchs adds the new Lightspeed receiver. Currently it seems to only be used in the G305. Signed-off-by: Filipe Laíns <lains@archlinux.org> [bentiss: rebased on top of master] Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
992ff2cc |
|
12-Aug-2019 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: add support of the G700(s) receiver Both the G700 and the G700s are sharing the same receiver. Include support for this receiver in hid-logitech-dj so that userspace can differentiate both. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
#
5b6cc127 |
|
29-Jul-2019 |
Olivier Gay <ogay@logitech.com> |
HID: logitech-dj: extend consumer usages range Extend the range of usage codes in the consumer page descriptor of the driver. Some Logitech HID devices send usages in that upper range. Signed-off-by: Olivier Gay <ogay@logitech.com> Tested-by: Benson Leung <bleung@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
6fb08f1a |
|
29-Jul-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: Really fix return value of logi_dj_recv_query_hidpp_devices Commit dbcbabf7da92 ("HID: logitech-dj: fix return value of logi_dj_recv_query_hidpp_devices") made logi_dj_recv_query_hidpp_devices return the return value of hid_hw_raw_request instead of unconditionally returning 0. But hid_hw_raw_request returns the report-size on a successful request (and a negative error-code on failure) where as the callers of logi_dj_recv_query_hidpp_devices expect a 0 return on success. This commit fixes things so that either the negative error gets returned or 0 on success, fixing HID++ receivers such as the Logitech nano receivers no longer working. Cc: YueHaibing <yuehaibing@huawei.com> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: dbcbabf7da92 ("HID: logitech-dj: fix return value of logi_dj_recv_query_hidpp_devices") Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reported-by: Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Rafael J. Wysocki <rjw@rjwysocki.net> Reviewed-by: Petr Vorel <pvorel@suse.cz> Tested-by: Petr Vorel <pvorel@suse.cz> Reviewed-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
d79f7bad |
|
16-Jul-2019 |
Filipe Laíns <lains@archlinux.org> |
HID: logitech-dj: add the Powerplay receiver Add device ID for Powerplay receiver. Signed-off-by: Filipe Laíns <lains@archlinux.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
600ea54d |
|
16-Jul-2019 |
Filipe Laíns <lains@archlinux.org> |
HID: logitech-dj: rename "gaming" receiver to "lightspeed" This should help people identify the receiver. there are several receivers used in gaming mice. the "lightspeed" technology is pretty well advertise so this won't just be an obscure name. Signed-off-by: Filipe Laíns <lains@archlinux.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
3a9a2c86 |
|
14-Jun-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: Fix forwarding of very long HID++ reports The HID++ spec also defines very long HID++ reports, with a reportid of 0x12. The MX5000 and MX5500 keyboards use 0x12 output reports for sending messages to display on their buildin LCD. Userspace (libmx5000) supports this, in order for this to work when talking to the HID devices instantiated for the keyboard by hid-logitech-dj, we need to properly forward these reports to the device. This commit fixes logi_dj_ll_raw_request not forwarding these reports. Fixes: f2113c3020ef ("HID: logitech-dj: add support for Logitech Bluetooth Mini-Receiver") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
dbcbabf7 |
|
25-May-2019 |
YueHaibing <yuehaibing@huawei.com> |
HID: logitech-dj: fix return value of logi_dj_recv_query_hidpp_devices We should return 'retval' as the correct return value instead of always zero. Fixes: 74808f9115ce ("HID: logitech-dj: add support for non unifying receivers") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
45051539 |
|
29-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 333 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111 1307 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 136 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190530000436.384967451@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
3ed224e2 |
|
05-Jun-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: Fix 064d:c52f receiver support The c52f nano receiver is a mouse only receiver. This means that it needs some special handling compared to the c534 nano receiver: 1) It sends unnumbered mouse reports with a size of 8 bytes, so we need to extend the unnumbered mouse report handling to support reports upto 8 bytes large 2) It mouse reports have the same high-resolution format as those from the gaming mouse receivers 3) It can report consumer/multimedia buttons on its second interface, since this is a mouse-only receiver these must be forwarded to the mouse child device and not to the keyboard child-device (which will not exist) Link: https://bugzilla.kernel.org/show_bug.cgi?id=203619 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
39d21e7e |
|
10-May-2019 |
Colin Ian King <colin.king@canonical.com> |
HID: logitech-dj: make const array template static Don't populate the array template on the stack but instead make it static. Makes the object code smaller by 10 bytes. Also reformat the declaration. Before: text data bss dec hex filename 29376 9360 128 38864 97d0 drivers/hid/hid-logitech-dj.o After: text data bss dec hex filename 29270 9456 128 38854 97c6 drivers/hid/hid-logitech-dj.o (gcc version 8.3.0, amd64) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
423dfbc3 |
|
09-May-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: Add usb-id for the 27MHz MX3000 receiver Testing has shown that, as expected, the MX3000 receiver is fully compatible with the existing 27MHz receiver support in hid-logitech-dj.c. After this the only, presumably also compatible, receiver id left in hid-lg.c is the USB_DEVICE_ID_S510_RECEIVER / 0xc50c id. If we can get someone to confirm that this receiver works with the dj 27Mhz support too, then the handling of the LG_RDESC and LG_WIRELESS quirks can be removed from hid-lg.c. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
b9a94fbe |
|
28-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: add support for the Logitech MX5500's Bluetooth Mini-Receiver Add support for the HID proxy mode of the Logitech Bluetooth Mini-Receiver which comes with the Logitech MX5500 keyboard. This receiver works the same as the Bluetooth Mini-Receiver coming with the MX5000 keyboard and also presents itself as an USB-hub with 2 separate USB devices for the keyboard (boot sub-class) interface and for the (boot sub-class) mouse interface. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
640d4ea8 |
|
26-Apr-2019 |
Colin Ian King <colin.king@canonical.com> |
HID: logitech-dj: fix spelling in printk There is a spelling mistake in a hid_err error message, fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
f2113c30 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: add support for Logitech Bluetooth Mini-Receiver Add support for the Logitech Bluetooth Mini-Receiver in HID proxy mode This requires some special handing in dj_find_receiver_dev because the BT Mini-Receiver contains a built-in hub and has separate USB-devices for the keyboard and mouse interfaces, rather then using 2 interfaces on a single USB device. Otherwise this receiver works identical to the standard non-unifying nano receivers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
6d3c3f03 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: make appending of the HID++ descriptors conditional Make the appending of the HID++ descriptors in logi_dj_ll_parse conditional. This is a preparation patch for adding support for the Logitech mini Bluetooth receiver in HID proxy mode (its default mode), where some of the paired devices may not be Logitech devices and thus may not be HID++ capable. This uses a fake bit 63 in reports_supported, which is changed from an u32 to an u64 for this. Bits <= 31 are not usable for this because that would cause a behavioral change in logi_dj_recv_forward_null_report. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
e316aa6e |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: remove false-positive error on double queueing of delayed-work The various functions queueing work-items do not check there already is a work-item queued before calling schedule_work(), as such they may race with each-other and with the re-queuing done by the delayedwork_callback itself. This is fine as the delayedwork_callback simply is a nop if scheduled once too much. I've actually seen the false-positive hid_err for this trigger in practice, so lets remove it. While at it also remove the somewhat overzealous debugging around the schedule_work() calls. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
de76b1d3 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: pick a better name for non-unifying receivers hidpp_unifying_get_name() does not work for devices attached to non-unifying receivers. Since we do get a device-type in the device- connection report, we can pick a better name for these devices in hid-logitech-dj.c . Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
da12b224 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: deal with some KVMs adding an extra interface to the usbdev My Aten cs1764a KVM adds an extra interface to the receiver through which it forwards mouse events, if a separate mouse is plugged in next to the receiver dongle. This interface is present even if no extra mouse is plugged in. logitech-dj trying to handle this extra interface causes mouse events send through the extra interface to not be properly handled. This commit fixes this by treating any extra interfaces as hid-generic interfaces. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
aca22a35 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: replace dev_err calls with hid_err calls Use hid_err consistently everywhere. While at it also tweak some of the messages for clarity, to consistently have a space after a ':' and in some cases to fit within 80 chars. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
1f944ac6 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: add support for 27 MHz mouse-only receivers 27 MHz mouse-only receivers send an unnumbered input report with the mouse data, add special handling for this and add the c51b product-id to the logi_dj_receivers table. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
c9121cf6 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: add support for 27 MHz receivers Most Logitech wireless keyboard and mice using the 27 MHz are hidpp10 devices, add support to logitech-dj for their receivers. Doing so leads to 2 improvements: 1) All these devices share the same USB product-id for their receiver, making it impossible to properly map some special keys / buttons which differ from device to device. Adding support to logitech-dj to see these as hidpp10 devices allows us to get the actual device-id from the keyboard / mouse. 2) It enables battery-monitoring of these devices This patch uses a new HID group for 27Mhz devices, since the logitech-hidpp code needs to be able to differentiate them from other devices instantiated by the logitech-dj code. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
f5fb57a7 |
|
20-Apr-2019 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: add support for the gaming unifying receiver This receiver is almost identical to the normal unifying ones except: - it is supposed to be paired to only one device (for performance reasons) - the mice reports have a greater ranges in their values, so they are using a different report ID. Tested on a G403 and a G900. Co-authored-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
74808f91 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: add support for non unifying receivers We emulate the DJ functionality through the driver. The receiver supports "fake device arrival" which behaves like the probing of DJ devices. A non-unifying receiver has 2 USB interfaces, the first one generates standard keypresses and is compatible with the USB Keyboard Boot Subclass. The second interface sends events for the mouse and special keys such as the consumer-page keys. Events are split this way for BIOS / Windows / generic-hid driver compatibility. This split does not actually match with which device the event originate from, e.g. the consumer-page key events originate from the keyboard but are delivered on the mouse interface. To make sure the events are actually delivered to the dj_device representing the originating device, we pick which dj_dev to forward a "regular" input-report to based on the report-number, rather then based on the originating interface. Co-authored-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
b6aeedde |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: add logi_dj_recv_queue_unknown_work helper Add a logi_dj_recv_queue_unknown_work helper and implement query rate-limiting inside this helper. The motivations behind this are: 1) We need to queue workitems for reports with no place to forward them from more places with the upcoming non-unifying receiver support, hence the addition of the helper function. 2) When we've missed a pairing info report (or there is a race between the report and input-events) and the input report is e.g. from a mouse being moved, we will get a lot of these before we've finished (re-) querying and enumerating the devices, hence the rate-limiting. Note this also removes the: if (!djrcv_dev->paired_dj_devices[hidpp_report->device_index]) check previously guarding the sending of an unknown workitem, the caller of logi_dj_recv_queue_notification already does this check before calling logi_dj_recv_queue_notification. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
a1d97ccb |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: support sharing struct dj_receiver_dev between USB-interfaces dj/HID++ receivers are really a single logical entity, but for BIOS/Windows compatibility they have multiple USB interfaces. For the upcoming non-unifying receiver support, we need to listen for events from / bind to all USB-interfaces of the receiver. This commit add support to the logitech-dj code for creating a single dj_receiver_dev struct for all interfaces belonging to a single USB-device / receiver, in preparation for adding non-unifying receiver support. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
0ee75544 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: rename dj_receiver_dev.hdev to dj_receiver_dev.hidpp For the upcoming non-unifying receiver support, we are going to bind to all USB-interfaces of a receiver, sharing a single struct dj_receiver_dev between the interfaces. This means that dj_receiver_dev will contain multiple pointers to a struct hid_device. Rename the current hdev member to hidpp to prepare for this. While at it switch dev_err calls which we are touching anyways from dev_err to hid_err. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
f41d766c |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: protect the paired_dj_devices access in add_djhid_dev with the lock This protects against logi_dj_recv_add_djhid_device, adding a device to paired_dj_devices from the delayedwork callback, racing versus logi_dj_raw_event trying to access that device. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
61d14de2 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-dj: remove unused querying_devices variable querying_devices is never set, so it can safely be removed. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
4fcad95a |
|
20-Apr-2019 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: do not schedule the dj report itself This is a preparatory patch for handling non DJ (HID++ only) receivers, through this module. We can not use the dj_report in the delayed work callback as the HID++ notifications are different both in size and meaning. There should be no functional change. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
82c0beb8 |
|
20-Apr-2019 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: remove USB dependency It is better to rely on the actual content of the report descriptors to enable or not a HID interface. While at it, remove the other USB dependency to have a fully USB agnostic driver. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
c0340412 |
|
20-Apr-2019 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: declare and use a few HID++ 1.0 constants For the non DJ receivers, we are going to need to re-use those constants, better have them properly defined. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
a17dd1f2 |
|
20-Apr-2019 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: use BIT() macro for RF Report types Use BIT() macro for RF Report types. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
7bb56a5f |
|
20-Apr-2019 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: fix variable naming in logi_dj_hidpp_event we are not dealing with a dj_report but a hidpp_event. We don't need all of the struct description in this function, but having the variable named `dj_report` feels weird. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
83898234 |
|
20-Apr-2019 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: reshuffle logi_dj_recv_forward_* logi_dj_recv_forward_report() was only intended for DJ reports. logi_dj_recv_forward_hidpp() is more generic at forwarding random HID reports. So rename logi_dj_recv_forward_report() into logi_dj_recv_forward_dj() and logi_dj_recv_forward_hidpp() into logi_dj_recv_forward_report(). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
43cd97af |
|
20-Apr-2019 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech: Stop setting drvdata to NULL on probe failure and remove There is no need to set drvdata to NULL on probe failure and remove, the driver-core already does this for us. [hdegoede@redhat.com: Isolate Logitech changes into a separate patch] Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
8dba3026 |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: allow devices to request full pairing information Register 0xB5 should be handled specially no matter what function is used. This allows to retrieve the serial and the Quad ID from hid-logitech-hidpp directly. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
f254ae93 |
|
16-Dec-2014 |
Peter Wu <peter@lekensteyn.nl> |
HID: logitech-dj: check report length Malicious USB devices can send bogus reports smaller than the expected buffer size. Ensure that the length is valid to avoid reading out of bounds. Signed-off-by: Peter Wu <peter@lekensteyn.nl> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
6a9ddc89 |
|
30-Sep-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: enable notifications on connect/disconnect The receiver can send HID++ notifications to the DJ devices when the physical devices are connected/disconnected. Enable this feature by default. This command uses a HID++ command instead of a DJ one, so use a direct call to usbhid instead of using logi_dj_recv_send_report() Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
33797820 |
|
30-Sep-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech: allow the DJ device to request the unifying name The names of the DJ devices are stored in the receiver. These names can be retrieved through a HID++ command. However, the protocol says that you have to ask the receiver for that, not the device iteself. Introduce a special case in the DJ handling where a device can request its unifying name, and when such a name is given, forward it also to the corresponding device. On the HID++ side, the receiver talks only HID++ 1.0, so we need to implement this part of the protocol in the module. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
925f0f3e |
|
30-Sep-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: allow transfer of HID++ reports from/to the correct dj device HID++ is a Logitech-specific protocol for communicating with HID devices. DJ devices implement HID++, and so we can add the HID++ collection in the report descriptor and forward the incoming reports from the receiver to the appropriate DJ device. The same can be done in the other way, if someone calls a .raw_request(), we can forward it to the correct dj device by overriding the device_index in the HID++ report. Signed-off-by: Benjamin Tisssoires <benjamin.tissoires@redhat.com> Tested-by: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
ab94e562 |
|
30-Sep-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech: move dj devices to the HID++ module Devices connected through the Logitech Wireless Receiver are HID++ devices. We can handle them here to benefit from this new module and activate enhaced support of the various wireless touchpad or mice with touch sensors on them. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
8cb3746a |
|
30-Sep-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: merge header file into the source There is no point in keeping the header in a separate file, nobody but hid-logitech-dj should have access to its content. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
d610274b |
|
30-Sep-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: rely on hid groups to separate receivers from dj devices Several benefits here: - we can drop the macro is_dj_device: I never been really conviced by this macro as we could fall into a null pointer anytime. Anyway time showed that this never happened. - we can simplify the hid driver logitech-djdevice, and make it aware of any new receiver VID/PID. - we can use the Wireless PID of the DJ device as the product id of the hid device, this way the sysfs will differentiate between different DJ devices. Signed-off-by: Benjamin Tisssoires <benjamin.tissoires@redhat.com> Tested-by: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
368d4e59 |
|
22-Aug-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: break out testing of validity of dj_device We can do once the test of the validity of the dj_device, which removes some duplicated code in various functions. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
5abfe85c |
|
22-Aug-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: prevent false errors to be shown Commit "HID: logitech: perform bounds checking on device_id early enough" unfortunately leaks some errors to dmesg which are not real ones: - if the report is not a DJ one, then there is not point in checking the device_id - the receiver (index 0) can also receive some notifications which can be safely ignored given the current implementation Move out the test regarding the report_id and also discards printing errors when the receiver got notified. Fixes: ad3e14d7c5268c2e24477c6ef54bbdf88add5d36 Cc: stable@vger.kernel.org Reported-and-tested-by: Markus Trippelsdorf <markus@trippelsdorf.de> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
ad3e14d7 |
|
21-Aug-2014 |
Jiri Kosina <jkosina@suse.cz> |
HID: logitech: perform bounds checking on device_id early enough device_index is a char type and the size of paired_dj_deivces is 7 elements, therefore proper bounds checking has to be applied to device_index before it is used. We are currently performing the bounds checking in logi_dj_recv_add_djhid_device(), which is too late, as malicious device could send REPORT_TYPE_NOTIF_DEVICE_UNPAIRED early enough and trigger the problem in one of the report forwarding functions called from logi_dj_raw_event(). Fix this by performing the check at the earliest possible ocasion in logi_dj_raw_event(). Cc: stable@vger.kernel.org Reported-by: Ben Hawkes <hawkes@google.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
51217e69 |
|
21-Aug-2014 |
Jiri Kosina <jkosina@suse.cz> |
HID: logitech: fix bounds checking on LED report size The check on report size for REPORT_TYPE_LEDS in logi_dj_ll_raw_request() is wrong; the current check doesn't make any sense -- the report allocated by HID core in hid_hw_raw_request() can be much larger than DJREPORT_SHORT_LENGTH, and currently logi_dj_ll_raw_request() doesn't handle this properly at all. Fix the check by actually trimming down the report size properly if it is too large. Cc: stable@vger.kernel.org Reported-by: Ben Hawkes <hawkes@google.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
bd27e202 |
|
09-Feb-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: remove hid_output_raw_report call hid-input do not use anymore hid_output_raw_report() to set the LEDs. Use the correct implementation now and make them working again. 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>
|
#
0e40d356 |
|
05-Feb-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: remove hidinput_input_event hid-logitech-dj uses its own ->hidinput_input_event() instead of the generic binding in hid-input. Moving the handling of LEDs towards logi_dj_output_hidraw_report() allows two things: - remove hidinput_input_event in struct hid_device - hidraw user space programs can also set the LEDs Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
42c22dbf |
|
08-Jan-2014 |
Benjamin Tisssoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: Fix USB 3.0 issue This fix (not very clean though) should fix the long time USB3 issue that was spotted last year. The rational has been given by Hans de Goede: ---- I think the most likely cause for this is a firmware bug in the unifying receiver, likely a race condition. The most prominent difference between having a USB-2 device plugged into an EHCI (so USB-2 only) port versus an XHCI port will be inter packet timing. Specifically if you send packets (ie hid reports) one at a time, then with the EHCI controller their will be a significant pause between them, where with XHCI they will be very close together in time. The reason for this is the difference in EHCI / XHCI controller OS <-> driver interfaces. For non periodic endpoints (control, bulk) the EHCI uses a circular linked-list of commands in dma-memory, which it follows to execute commands, if the list is empty, it will go into an idle state and re-check periodically. The XHCI uses a ring of commands per endpoint, and if the OS places anything new on the ring it will do an ioport write, waking up the XHCI making it send the new packet immediately. For periodic transfers (isoc, interrupt) the delay between packets when sending one at a time (rather then queuing them up) will be even larger, because they need to be inserted into the EHCI schedule 2 ms in the future so the OS driver can be sure that the EHCI driver does not try to start executing the time slot in question before the insertion has completed. So a possible fix may be to insert a delay between packets being send to the receiver. ---- I tested this on a buggy Haswell USB 3.0 motherboard, and I always get the notification after adding the msleep. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
6d603326 |
|
18-Oct-2013 |
Dan Carpenter <dan.carpenter@oracle.com> |
HID: logitech-dj: small cleanup in rdcat() We could pass the "rdsec" pointer instead of the address of the "rdesc" and it's a little simpler. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
297502ab |
|
11-Sep-2013 |
Kees Cook <keescook@chromium.org> |
HID: logitech-dj: validate output report details A HID device could send a malicious output report that would cause the logitech-dj HID driver to leak kernel memory contents to the device, or trigger a NULL dereference during initialization: [ 304.424553] usb 1-1: New USB device found, idVendor=046d, idProduct=c52b ... [ 304.780467] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 [ 304.781409] IP: [<ffffffff815d50aa>] logi_dj_recv_send_report.isra.11+0x1a/0x90 CVE-2013-2895 Signed-off-by: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
8e5654ce |
|
09-Aug-2013 |
Jiri Kosina <jkosina@suse.cz> |
Revert "HID: hid-logitech-dj: querying_devices was never set" This reverts commit 407a2c2a4d85100c8c67953e4bac2f4a6c942335. Explanation provided by Benjamin Tissoires: Commit "HID: hid-logitech-dj, querying_devices was never set" activate a flag which guarantees that we do not ask the receiver for too many enumeration. When the flag is set, each following enumeration call is discarded (the usb request is not forwarded to the receiver). The flag is then released when the driver receive a pairing information event, which normally follows the enumeration request. However, the USB3 bug makes the driver think the enumeration request has been forwarded to the receiver. However, it is actually not the case because the USB stack returns -EPIPE. So, when a new unknown device appears, the workaround consisting in asking for a new enumeration is not working anymore: this new enumeration is discarded because of the flag, which is never reset. A solution could be to trigger a timeout before releasing it, but for now, let's just revert the patch. Reported-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Tested-by: Sune Mølgaard <sune@molgaard.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
ce737368 |
|
31-Jul-2013 |
Peter Hurley <peter@hurleysoftware.com> |
HID: logitech-dj: Fix non-atomic kmalloc in logi_dj_ll_input_event() The ll_driver's .hidinput_input_event() method is called from atomic context [1]. Use GFP_ATOMIC for allocation of the synthesized hid report. BUG: sleeping function called from invalid context at /home/peter/src/kernels/next/mm/slub.c:941 in_atomic(): 1, irqs_disabled(): 1, pid: 2095, name: Xorg INFO: lockdep is turned off. irq event stamp: 1502178 hardirqs last enabled at (1502177): [<ffffffff81785e55>] _raw_spin_unlock_irqrestore+0x65/0x80 hardirqs last disabled at (1502178): [<ffffffff8178632a>] common_interrupt+0x6a/0x6f softirqs last enabled at (1501802): [<ffffffff81051ed3>] __do_softirq+0x183/0x420 softirqs last disabled at (1501799): [<ffffffff81052315>] irq_exit+0xb5/0xc0 CPU: 3 PID: 2095 Comm: Xorg Not tainted 3.11-next-20130725-xeon+lockdep #20130725 Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11 04/30/2012 ffffffff81a662e0 ffff8802adcf9ca8 ffffffff8177c330 0000000000000000 ffff8802a76d2440 ffff8802adcf9cd8 ffffffff810867d0 ffff8802a7ac8000 0000000000000010 00000000ffffffff 00000000000000d0 ffff8802adcf9d38 Call Trace: [<ffffffff8177c330>] dump_stack+0x4f/0x84 [<ffffffff810867d0>] __might_sleep+0x140/0x1f0 [<ffffffff811ad93b>] __kmalloc+0x6b/0x2e0 [<ffffffffa026cb08>] ? hid_alloc_report_buf+0x28/0x30 [hid] [<ffffffffa026cb08>] hid_alloc_report_buf+0x28/0x30 [hid] [<ffffffffa00700b0>] logi_dj_ll_input_event+0xb0/0x1b0 [hid_logitech_dj] [<ffffffff815a559e>] input_handle_event+0x8e/0x540 [<ffffffff815a5aad>] ? input_inject_event+0x5d/0x220 [<ffffffff815a5c10>] input_inject_event+0x1c0/0x220 [<ffffffff815a5a94>] ? input_inject_event+0x44/0x220 [<ffffffff81181660>] ? might_fault+0xa0/0xb0 [<ffffffff81181617>] ? might_fault+0x57/0xb0 [<ffffffff815a909e>] evdev_write+0xde/0x160 [<ffffffff811c0ad8>] vfs_write+0xc8/0x1f0 [<ffffffff811c0fe5>] SyS_write+0x55/0xa0 [<ffffffff8178e682>] system_call_fastpath+0x16/0x1b Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
407a2c2a |
|
18-Jul-2013 |
Nestor Lopez Casado <nlopezcasad@logitech.com> |
HID: hid-logitech-dj: querying_devices was never set 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: Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
c63e0e37 |
|
18-Jul-2013 |
Nestor Lopez Casado <nlopezcasad@logitech.com> |
HID: Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue"" This reverts commit 8af6c08830b1ae114d1a8b548b1f8b056e068887. This patch re-adds the workaround introduced by 596264082f10dd4 which was reverted by 8af6c08830b1ae114. 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 c849a6143bec520af 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 a9dd22b730857347 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 8af6c08. 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 dcd9006b1b053c7b1c 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/1194649 Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
27ce4050 |
|
10-Jul-2013 |
Jiri Kosina <jkosina@suse.cz> |
HID: fix data access in implement() 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>
|
#
ddf7540e |
|
12-Jul-2013 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: use inlined helpers hid_hw_open/close Use the inlined helpers hid_hw_open/close instead of direct calls to ->ll_driver->open() and ->ll_driver->close(). Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
dcd9006b |
|
05-Mar-2013 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-dj: do not directly call hid_output_raw_report() during probe 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=49781 Reported-and-tested-by: Bob Bowles <bobjohnbowles@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
8af6c088 |
|
18-Feb-2013 |
Andrew de los Reyes <adlr@chromium.org> |
Revert "HID: Fix logitech-dj: missing Unifying device issue" This reverts commit 596264082f10dd4a567c43d4526b2f54ac5520bc. 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: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
a9dd22b7 |
|
18-Feb-2013 |
Andrew de los Reyes <adlr@chromium.org> |
HID: logitech-dj: Allow incoming packets during probe(). 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 596264082f10dd4a56 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: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
d8814272 |
|
25-Feb-2013 |
Benjamin Tissoires <benjamin.tissoires@gmail.com> |
HID: use hid_hw_request() instead of direct call to usbhid 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: Benjamin Tissoires <benjamin.tissoires@gmail.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> For the sensor-hub part: Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
59626408 |
|
20-Sep-2012 |
Nestor Lopez Casado <nlopezcasad@logitech.com> |
HID: Fix logitech-dj: missing Unifying device issue This patch fixes an issue introduced after commit 4ea5454203d991ec ("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: Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
8a55ade7 |
|
04-Sep-2012 |
Alan Cox <alan@linux.intel.com> |
dj: memory scribble in logi_dj Allocate a structure not a pointer to it ! Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
d8dc3494 |
|
01-Jun-2012 |
Marc Dionne <marc.c.dionne@gmail.com> |
HID: logitech: don't use stack based dj_report structures 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: Marc Dionne <marc.c.dionne@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
44d27f7d |
|
11-May-2012 |
Jonathan Nieder <jrnieder@gmail.com> |
HID: logitech: read all 32 bits of report type bitfield 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/671292 Reported-by: Hugo Osvaldo Barrera <hugo@osvaldobarrera.com.ar> Inspired-by: Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com> Cc: <stable@vger.kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
2a039bf5 |
|
22-Apr-2012 |
Henrik Rydberg <rydberg@euromail.se> |
HID: hid-logitech: Collect report descriptors before sending 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: Henrik Rydberg <rydberg@euromail.se> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
76503166 |
|
02-Feb-2012 |
Nestor Lopez Casado <nlopezcasad@logitech.com> |
HID: logitech: fix mask to enable DJ mode 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: Nestor Lopez Casado <nlopezcasad@logitech.com> drivers/hid/hid-logitech-dj.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
844580ff |
|
20-Sep-2011 |
Nestor Lopez Casado <nlopezcasad@logitech.com> |
HID: hid-logitech-dj: fix off by one 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: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Reviewed-by: Olivier Gay <ogay@logitech.com> Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
534a7b8e |
|
15-Sep-2011 |
Nestor Lopez Casado <nlopezcasad@logitech.com> |
HID: Add full support for Logitech Unifying receivers 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: Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|