summaryrefslogtreecommitdiffstats
path: root/drivers/hid/hid-logitech-dj.c
Commit message (Collapse)AuthorAgeFilesLines
* HID: logitech-dj: Really fix return value of logi_dj_recv_query_hidpp_devicesHans de Goede2019-08-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* HID: logitech-dj: add the Powerplay receiverFilipe Laíns2019-07-171-0/+4
| | | | | | | Add device ID for Powerplay receiver. Signed-off-by: Filipe Laíns <lains@archlinux.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-dj: rename "gaming" receiver to "lightspeed"Filipe Laíns2019-07-171-2/+2
| | | | | | | | | 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>
*-----. Merge branches 'for-5.2/fixes', 'for-5.3/doc', 'for-5.3/ish', ↵Jiri Kosina2019-07-101-23/+13Star
|\ \ \ \ | | | | | | | | | | | | | | | 'for-5.3/logitech' and 'for-5.3/wacom' into for-linus
| | | * | HID: logitech-dj: fix return value of logi_dj_recv_query_hidpp_devicesYueHaibing2019-06-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | | * | HID: logitech-dj: make const array template staticColin Ian King2019-05-221-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | | * | HID: logitech-dj: Add usb-id for the 27MHz MX3000 receiverHans de Goede2019-05-091-0/+3
| | | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | Merge branch 'for-linus' of ↵Linus Torvalds2019-06-281-1/+3
| |\ \ \ | |/ / / |/| / / | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Jiri Kosina: - fix for one corner case in HID++ protocol with respect to handling very long reports, from Hans de Goede - power management fix in Intel-ISH driver, from Hyungwoo Yang - use-after-free fix in Intel-ISH driver, from Dan Carpenter - a couple of new device IDs/quirks from Kai-Heng Feng, Kyle Godbey and Oleksandr Natalenko * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: intel-ish-hid: fix wrong driver_data usage HID: multitouch: Add pointstick support for ALPS Touchpad HID: logitech-dj: Fix forwarding of very long HID++ reports HID: uclogic: Add support for Huion HS64 tablet HID: chicony: add another quirk for PixArt mouse HID: intel-ish-hid: Fix a use after free in load_fw_from_host()
| * | Merge branch 'for-linus' of ↵Linus Torvalds2019-06-131-15/+35
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Jiri Kosina: - regression fixes (reverts) for module loading changes that turned out to be incompatible with some userspace, from Benjamin Tissoires - regression fix for special Logitech unifiying receiver 0xc52f, from Hans de Goede - a few device ID additions to logitech driver, from Hans de Goede - fix for Bluetooth support on 2nd-gen Wacom Intuos Pro, from Jason Gerecke * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: logitech-dj: Fix 064d:c52f receiver support Revert "HID: core: Call request_module before doing device_add" Revert "HID: core: Do not call request_module() in async context" Revert "HID: Increase maximum report size allowed by hid_field_extract()" HID: a4tech: fix horizontal scrolling HID: hyperv: Add a module description line HID: logitech-hidpp: Add support for the S510 remote control HID: multitouch: handle faulty Elo touch device HID: wacom: Sync INTUOSP2_BT touch state after each frame if necessary HID: wacom: Correct button numbering 2nd-gen Intuos Pro over Bluetooth HID: wacom: Send BTN_TOUCH in response to INTUOSP2_BT eraser contact HID: wacom: Don't report anything prior to the tool entering range HID: wacom: Don't set tool type until we're in range HID: rmi: Use SET_REPORT request on control endpoint for Acer Switch 3 and 5 HID: logitech-hidpp: add support for the MX5500 keyboard HID: logitech-dj: add support for the Logitech MX5500's Bluetooth Mini-Receiver HID: i2c-hid: add iBall Aer3 to descriptor override
| * | | treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 333Thomas Gleixner2019-06-051-16/+1Star
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | HID: logitech-dj: Fix forwarding of very long HID++ reportsHans de Goede2019-06-261-1/+3
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | HID: logitech-dj: Fix 064d:c52f receiver supportHans de Goede2019-06-051-15/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | HID: logitech-dj: add support for the Logitech MX5500's Bluetooth Mini-ReceiverHans de Goede2019-05-091-0/+8
|/ | | | | | | | | | | 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>
* HID: logitech-dj: fix spelling in printkColin Ian King2019-04-301-1/+1
| | | | | | | 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>
* HID: logitech-dj: add support for Logitech Bluetooth Mini-ReceiverHans de Goede2019-04-231-6/+85
| | | | | | | | | | | | | 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>
* HID: logitech-dj: make appending of the HID++ descriptors conditionalHans de Goede2019-04-231-14/+21
| | | | | | | | | | | | | | | 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>
* HID: logitech-dj: remove false-positive error on double queueing of delayed-workHans de Goede2019-04-231-18/+4Star
| | | | | | | | | | | | | | | | | 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>
* HID: logitech-dj: pick a better name for non-unifying receiversHans de Goede2019-04-231-5/+29
| | | | | | | | | | 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>
* HID: logitech-dj: deal with some KVMs adding an extra interface to the usbdevHans de Goede2019-04-231-1/+31
| | | | | | | | | | | | | | | | 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>
* HID: logitech-dj: replace dev_err calls with hid_err callsHans de Goede2019-04-231-27/+18Star
| | | | | | | | | | | 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>
* HID: logitech-dj: add support for 27 MHz mouse-only receiversHans de Goede2019-04-231-0/+14
| | | | | | | | | 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>
* HID: logitech-dj: add support for 27 MHz receiversHans de Goede2019-04-231-1/+93
| | | | | | | | | | | | | | | | | | | | | | 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>
* HID: logitech-dj: add support for the gaming unifying receiverBenjamin Tissoires2019-04-231-1/+57
| | | | | | | | | | | | | 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>
* HID: logitech-dj: add support for non unifying receiversHans de Goede2019-04-231-39/+272
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* HID: logitech-dj: add logi_dj_recv_queue_unknown_work helperHans de Goede2019-04-231-15/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* HID: logitech-dj: support sharing struct dj_receiver_dev between USB-interfacesHans de Goede2019-04-231-27/+149
| | | | | | | | | | | | | | | 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>
* HID: logitech-dj: rename dj_receiver_dev.hdev to dj_receiver_dev.hidppHans de Goede2019-04-231-12/+10Star
| | | | | | | | | | | | | | 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>
* HID: logitech-dj: protect the paired_dj_devices access in add_djhid_dev with ↵Hans de Goede2019-04-231-0/+6
| | | | | | | | | | | 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>
* HID: logitech-dj: remove unused querying_devices variableHans de Goede2019-04-231-5/+0Star
| | | | | | | 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>
* HID: logitech-dj: do not schedule the dj report itselfBenjamin Tissoires2019-04-231-51/+85
| | | | | | | | | | | 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>
* HID: logitech-dj: remove USB dependencyBenjamin Tissoires2019-04-231-33/+35
| | | | | | | | | | | 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>
* HID: logitech-dj: declare and use a few HID++ 1.0 constantsBenjamin Tissoires2019-04-231-3/+12
| | | | | | | | 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>
* HID: logitech-dj: use BIT() macro for RF Report typesBenjamin Tissoires2019-04-231-6/+6
| | | | | | | 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>
* HID: logitech-dj: fix variable naming in logi_dj_hidpp_eventBenjamin Tissoires2019-04-231-3/+10
| | | | | | | | | 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>
* HID: logitech-dj: reshuffle logi_dj_recv_forward_*Benjamin Tissoires2019-04-231-7/+7
| | | | | | | | | | | | 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>
* HID: logitech: Stop setting drvdata to NULL on probe failure and removeBenjamin Tissoires2019-04-231-2/+0Star
| | | | | | | | | 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>
* HID: logitech-dj: allow devices to request full pairing informationBenjamin Tissoires2017-04-061-8/+11
| | | | | | | | | | 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>
* HID: logitech-dj: check report lengthPeter Wu2014-12-171-1/+15
| | | | | | | | | | 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>
* HID: logitech-dj: enable notifications on connect/disconnectBenjamin Tissoires2014-10-291-1/+26
| | | | | | | | | | | | | 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>
* HID: logitech: allow the DJ device to request the unifying nameBenjamin Tissoires2014-10-291-3/+21
| | | | | | | | | | | | | | | | | 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>
* HID: logitech-dj: allow transfer of HID++ reports from/to the correct dj deviceBenjamin Tissoires2014-10-291-28/+160
| | | | | | | | | | | | | | | 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>
* HID: logitech: move dj devices to the HID++ moduleBenjamin Tissoires2014-10-291-41/+1Star
| | | | | | | | | | | 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>
* HID: logitech-dj: merge header file into the sourceBenjamin Tissoires2014-10-291-1/+87
| | | | | | | | | 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>
* HID: logitech-dj: rely on hid groups to separate receivers from dj devicesBenjamin Tissoires2014-10-291-28/+10Star
| | | | | | | | | | | | | | | | 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>
* HID: logitech-dj: break out testing of validity of dj_deviceBenjamin Tissoires2014-08-271-24/+11Star
| | | | | | | | 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>
* HID: logitech-dj: prevent false errors to be shownBenjamin Tissoires2014-08-251-18/+25
| | | | | | | | | | | | | | | | | | | | 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>
* HID: logitech: perform bounds checking on device_id early enoughJiri Kosina2014-08-211-7/+6Star
| | | | | | | | | | | | | | | | | | | | 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>
* HID: logitech: fix bounds checking on LED report sizeJiri Kosina2014-08-211-1/+1
| | | | | | | | | | | | | | | | 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>
* HID: logitech-dj: remove hid_output_raw_report callBenjamin Tissoires2014-02-171-15/+6Star
| | | | | | | | | 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>
* HID: logitech-dj: remove hidinput_input_eventBenjamin Tissoires2014-02-171-64/+42Star
| | | | | | | | | | | | 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>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-06-10 19:41:37 +0200