#
411a20db |
|
29-Jan-2024 |
Oleksandr Natalenko <oleksandr@natalenko.name> |
HID: logitech-hidpp: Do not flood kernel log Since commit 680ee411a98e ("HID: logitech-hidpp: Fix connect event race") the following messages appear in the kernel log from time to time: logitech-hidpp-device 0003:046D:408A.0005: HID++ 4.5 device connected. logitech-hidpp-device 0003:046D:408A.0005: HID++ 4.5 device connected. logitech-hidpp-device 0003:046D:4051.0006: Disconnected logitech-hidpp-device 0003:046D:408A.0005: Disconnected As discussed, print the first per-device "device connected" message at info level, demoting subsequent messages to debug level. Also, demote the "Disconnected message" to debug level unconditionally. Link: https://lore.kernel.org/lkml/3277085.44csPzL39Z@natalenko.name/ Signed-off-by: Oleksandr Natalenko <oleksandr@natalenko.name> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
#
afa6ac26 |
|
22-Jan-2024 |
Jiri Kosina <jikos@kernel.org> |
HID: logitech-hidpp: add support for Logitech G Pro X Superlight 2 Let logitech-hidpp driver claim Logitech G Pro X Superlight 2. Reported-by: Marcus Rückert <darix@opensu.se> Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
#
3e6b0bb2 |
|
25-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Stop IO before calling hid_connect() hid_connect() will call hid_pidff_init() which does hid_device_io_start() leading to an "io already started" warning. To fix this call hid_device_io_stop() before calling hid_connect(), stopping IO means that connect events may be lost while hid_connect() runs, re-enable IO and move the hidpp_connect_event() work queuing after the hid_connect(). Note re-enabling IO is also necessary for the g920_get_config() call later during hidpp_probe(). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231025190151.302376-1-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
9ce363aa |
|
09-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Drop HIDPP_QUIRK_UNIFYING HIDPP unifying is only checked once in probe() and it is also set by probe() itself. Drop the quirk and replace its one check by the condition which is used to set the quirk in the first place. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-13-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
f3c4ee71 |
|
09-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Drop delayed_work_cb() Drop delayed_work_cb() instead make hidpp_connect_event() the workqueue function itself. Besides resulting in a small cleanup this will hopefully also make it clearer that going forward hidpp_connect_event() should only be run from a workqueue and not be directly invoked. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-12-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
680ee411 |
|
09-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Fix connect event race There is a connect event race in hidpp_probe() in these 2 lines: connected = hidpp_root_get_protocol_version(hidpp) == 0; atomic_set(&hidpp->connected, connected); Specifically the following can happen: 1. This line from hidpp_probe() is executed: connected = hidpp_root_get_protocol_version(hidpp) == 0; and sets connected to false; 2. A connect-event packet is received and does: atomic_set(&hidpp->connected, true); 3. The next line from hidpp_probe() is executed: atomic_set(&hidpp->connected, connected); and sets the atomic_t back to 0 again. 4. hidpp_connect_event() runs and sees the connected device as disconnected because of this. To fix this make hidpp_connect_event() query the connection status of the device itself instead of having it rely on possibly stale data cached in struct hidpp_device. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-11-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
bb17b2c6 |
|
09-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Remove unused connected param from *_connect() Remove the unused connected function parameter from wtp_connect(), m560_send_config_command() and k400_connect(). This is a preparation patch for moving all connected state handling to hidpp_connect_event(). This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-10-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
6f335b47 |
|
09-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Remove connected check for non-unifying devices Non-unifying devices (USB, Bluetooth) are always connected during probe(), remove the unnecessary connected check. This is a preparation patch for moving all connected state handling to hidpp_connect_event(). This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-9-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
c14f1485 |
|
09-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Add hidpp_non_unifying_init() helper Turn hidpp_overwrite_name() into a hidpp_non_unifying_init() helper which takes care of setting both the name and the serial for non unifying devices. This mirrors the hidpp_unifying_init() helper for unifying devices. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-8-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
8954dac1 |
|
09-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Move hidpp_overwrite_name() to before connect check Move the hidpp_overwrite_name() call to before the connect check, this puts it at the same place in the probe() order as hidpp_serial_init() which seems more logical. This should not make a difference since this is in the non-unifying path and only unifying devices can be probed in non-connected state. This is a preparation patch for moving all connected state handling to hidpp_connect_event(). Doing this before the connect check requires dropping the protocol version check since protocol_major is not set yet now. Instead this relies on hidpp_root_get_feature(HIDPP_PAGE_GET_DEVICE_NAME_TYPE) failing on older devices, just like how hidpp_get_serial() relies on hidpp_root_get_feature(HIDPP_PAGE_DEVICE_INFORMATION) failing on older devices. So this again makes the code more consistent. Also stop printing an error on failure now, since with the proto version check gone failures are expected to happen on older devices. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-7-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
219ccfb6 |
|
09-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Move g920_get_config() to just before hidpp_ff_init() The data retrieved by g920_get_config() is only used by hidpp_ff_init(). Now that the hw is kept open till the end of probe() the g920_get_config() call can be moved to just before hidpp_ff_init() to have all the HIDPP_QUIRK_CLASS_G920 together in a single place. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-6-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
a3643036 |
|
09-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Remove wtp_get_config() call from probe() For WTP devices which start disconnected (paired with the unifying receiver, but not connected atm) hidpp_connect_event() takes care of calling wtp_get_config() when the device later connects. There is no need to have a separate code path for WTP devices which are connected at probe() time, these can use the same code-path since probe() will queue hidpp_connect_event() for those at probe time. Drop the unnecessary wtp_get_config() call from probe(). This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-5-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
ba9de350 |
|
09-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Move get_wireless_feature_index() check to hidpp_connect_event() Calling get_wireless_feature_index() from probe() causes the wireless_feature_index to only get set for unifying devices which are already connected at probe() time. It does not get set for devices which connect later. Fix this by moving get_wireless_feature_index() to hidpp_connect_event(), this does not make a difference for devices connected at probe() since probe() will queue the hidpp_connect_event() for those at probe time. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Fixes: 0da0a63b7cba ("HID: logitech-hidpp: Support WirelessDeviceStatus connect events") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-4-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
55bf7036 |
|
09-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Revert "Don't restart communication if not necessary" Commit 91cf9a98ae41 ("HID: logitech-hidpp: make .probe usbhid capable") makes hidpp_probe() first call hid_hw_start(hdev, 0) to allow IO without connecting any hid subdrivers (hid-input, hidraw). This is done to allow to retrieve the device's name and serial number and store these in hdev->name and hdev->uniq. Then later on IO was stopped and started again with hid_hw_start(hdev, HID_CONNECT_DEFAULT) connecting hid-input and hidraw after the name and serial number have been setup. Commit 498ba2069035 ("HID: logitech-hidpp: Don't restart communication if not necessary") changed the probe() code to only do the start with a 0 connect-mask + restart later for unifying devices. But for non unifying devices hdev->name and hdev->uniq are updated too. So this change re-introduces the problem for which the start with a 0 connect-mask + restart later behavior was introduced. The previous patch in this series changes the unifying path to instead of restarting IO only call hid_connect() later. This avoids possible issues with restarting IO seen on non unifying devices. Revert the change to limit the restart behavior to unifying devices to fix hdev->name changing after userspace facing devices have already been registered. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Fixes: 498ba2069035 ("HID: logitech-hidpp: Don't restart communication if not necessary") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-3-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
11ca0322 |
|
09-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Don't restart IO, instead defer hid_connect() only Restarting IO causes 2 problems: 1. Some devices do not like IO being restarted this was addressed in commit 498ba2069035 ("HID: logitech-hidpp: Don't restart communication if not necessary"), but that change has issues of its own and needs to be reverted. 2. Restarting IO and specifically calling hid_device_io_stop() causes received packets to be missed, which may cause connect-events to get missed. Restarting IO was introduced in commit 91cf9a98ae41 ("HID: logitech-hidpp: make .probe usbhid capable") to allow to retrieve the device's name and serial number and store these in hdev->name and hdev->uniq before connecting any hid subdrivers (hid-input, hidraw) exporting this info to userspace. But this does not require restarting IO, this merely requires deferring calling hid_connect(). Calling hid_hw_start() with a connect-mask of 0 makes it skip calling hid_connect(), so hidpp_probe() can simply call hid_connect() later without needing to restart IO. Remove the stop + restart of IO and instead just call hid_connect() later to avoid the issues caused by restarting IO. Now that IO is no longer stopped, hid_hw_close() must be called at the end of probe() to balance the hid_hw_open() done at the beginning probe(). This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Fixes: 498ba2069035 ("HID: logitech-hidpp: Don't restart communication if not necessary") Suggested-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-2-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
dac50139 |
|
05-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: power_supply_unregister+0x8e/0xa0 Sep 22 20:01:35 eric kernel: release_nodes+0x3d/0xb0 Sep 22 20:01:35 eric kernel: devres_release_group+0xfc/0x130 Sep 22 20:01:35 eric kernel: hid_device_remove+0x56/0xa0 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? __queue_work+0x1df/0x440 Sep 22 20:01:35 eric kernel: hid_destroy_device+0x4b/0x60 Sep 22 20:01:35 eric kernel: logi_dj_remove+0x9a/0x100 [hid_logitech_dj 5c91534a0ead2b65e04dd799a0437e3b99b21bc4] Sep 22 20:01:35 eric kernel: hid_device_remove+0x44/0xa0 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? __queue_work+0x1df/0x440 Sep 22 20:01:35 eric kernel: hid_destroy_device+0x4b/0x60 Sep 22 20:01:35 eric kernel: usbhid_disconnect+0x47/0x60 [usbhid 727dcc1c0b94e6b4418727a468398ac3bca492f3] Sep 22 20:01:35 eric kernel: usb_unbind_interface+0x90/0x270 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? kobject_put+0xa0/0x1d0 Sep 22 20:01:35 eric kernel: usb_disable_device+0xcd/0x1e0 Sep 22 20:01:35 eric kernel: usb_disconnect+0xde/0x2c0 Sep 22 20:01:35 eric kernel: usb_disconnect+0xc3/0x2c0 Sep 22 20:01:35 eric kernel: hub_event+0xe80/0x1c10 There have been quite a few bug reports (see Link tags) about this crash. Fix all the TOCTOU issues, including the really bad power-supply related system crash on USB disconnect, by making probe() use the workqueue for running hidpp_connect_event() too, so that it can never run more then once. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227221 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2242189 Link: https://bugzilla.kernel.org/show_bug.cgi?id=217412#c58 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231005182638.3776-1-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
2d866603 |
|
27-Aug-2023 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Add Bluetooth ID for the Logitech M720 Triathlon mouse Using hidpp for the M720 adds battery info reporting and hires scrolling support. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
60165ab7 |
|
12-Jul-2023 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: rework one more time the retries attempts Extract the internal code inside a helper function, fix the initialization of the parameters used in the helper function (`hidpp->answer_available` was not reset and `*response` wasn't either), and use a `do {...} while();` loop. Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy") Cc: stable@vger.kernel.org Reviewed-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20230621-logitech-fixes-v2-1-3635f7f9c8af@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
ed1fb63b |
|
09-Aug-2023 |
Maxim Mikityanskiy <maxtram95@gmail.com> |
HID: logitech-hidpp: Add support for Logitech MX Anywhere 3 mouse Add Logitech MX Anywhere 3 connected over Bluetooth to the device table to get hidpi scroll supported. USB connection over the Unifying receiver is already supported by the wildcard entry LDJ_DEVICE(HID_ANY_ID). Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com> Reviewed-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
c05b8a93 |
|
16-Jul-2023 |
Mavroudis Chatzilazaridis <mavchatz@protonmail.com> |
HID: logitech-hidpp: Add support for the Pro X Superlight This patch adds support for the Pro X Superlight over wired USB. The device now reports the status of its battery. 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>
|
#
a7156d81 |
|
20-Jun-2023 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Rename HID++ "internal" error constant As per the upstream "hidpp" helpers commit: " There has been some confusion about error value 5 but feature specs that refer to it generally use NOT_ALLOWED. " Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://github.com/mrubli2/hidpp/commit/80c3fecfcd89c5efe0f16feabe90a55ddfd25aaa Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
a343a768 |
|
29-Jun-2023 |
Stuart Hayhurst <stuart.a.hayhurst@gmail.com> |
HID: logitech-hidpp: Add wired USB id for Logitech G502 Lightspeed Previously, support for the G502 had been attempted in commit '27fc32fd9417 ("HID: logitech-hidpp: add USB PID for a few more supported mice")' This caused some issues and was reverted by 'addf3382c47c ("Revert "HID: logitech-hidpp: add USB PID for a few more supported mice"")'. Since then, a new version of this mouse has been released (Lightpseed Wireless), and works correctly. This device has support for battery reporting with the driver Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com> Reviewed-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230630113818.13005-1-stuart.a.hayhurst@gmail.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
#
5fe25111 |
|
17-Jun-2023 |
Mike Hommey <mh@glandium.org> |
HID: logitech-hidpp: add HIDPP_QUIRK_DELAYED_INIT for the T651. commit 498ba2069035 ("HID: logitech-hidpp: Don't restart communication if not necessary") put restarting communication behind that flag, and this was apparently necessary on the T651, but the flag was not set for it. Fixes: 498ba2069035 ("HID: logitech-hidpp: Don't restart communication if not necessary") Cc: stable@vger.kernel.org Signed-off-by: Mike Hommey <mh@glandium.org> Link: https://lore.kernel.org/r/20230617230957.6mx73th4blv7owqk@glandium.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
48aea8b4 |
|
30-May-2023 |
stuarthayhurst <stuart.a.hayhurst@gmail.com> |
HID: logitech-hidpp: Add USB and Bluetooth IDs for the Logitech G915 TKL Keyboard Adds the USB and Bluetooth IDs for the Logitech G915 TKL keyboard, for device detection For this device, this provides battery reporting on top of hid-generic Reviewed-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
7c28afd5 |
|
05-Jun-2023 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: hidpp: terminate retry loop on success It seems we forgot the normal case to terminate the retry loop, making us asking 3 times each command, which is probably a little bit too much. And remove the ugly "goto exit" that can be replaced by a simpler "break" Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy") Suggested-by: Mark Lord <mlord@pobox.com> Tested-by: Mark Lord <mlord@pobox.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
6199d23c |
|
31-May-2023 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Handle timeout differently from busy If an attempt at contacting a receiver or a device fails because the receiver or device never responds, don't restart the communication, only restart it if the receiver or device answers that it's busy, as originally intended. This was the behaviour on communication timeout before commit 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy"). This fixes some overly long waits in a critical path on boot, when checking whether the device is connected by getting its HID++ version. Signed-off-by: Bastien Nocera <hadess@hadess.net> Suggested-by: Mark Lord <mlord@pobox.com> Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217412 Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
d9d5623f |
|
02-Mar-2023 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Set wireless_status for G935 receiver Set the USB interface "wireless_status" for the G935 receiver when receiving battery notifications. This will allow sound daemons such as Pipewire or PulseAudio to know whether or not the headset is turned on and connected. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230302105555.51417-6-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
4a1529f4 |
|
02-Mar-2023 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Add Logitech G935 headset Add the Logitech G935 headset that uses the HID++ protocol to the list of supported devices. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230302105555.51417-3-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
c361982a |
|
02-Mar-2023 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Add support for ADC measurement feature This is used in a number of Logitech headsets to report the voltage of the battery. Tested on a Logitech G935. Signed-off-by: Bastien Nocera <hadess@hadess.net> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216483 Link: https://lore.kernel.org/r/20230302105555.51417-2-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
e0138763 |
|
02-Mar-2023 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Simplify array length check Use the compiler to force a 100-length array, rather than check the length after the fact. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230302105555.51417-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
5b3691d1 |
|
02-Mar-2023 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Reconcile USB and Unifying serials Now that USB HID++ devices can gather a serial number that matches the one that would be gathered when connected through a Unifying receiver, remove the last difference by dropping the product ID as devices usually have different product IDs when connected through USB or Unifying. For example, on the serials on a G903 wired/wireless mouse: - Unifying before patch: 4067-e8-ce-cd-45 - USB before patch: c086-e8-ce-cd-45 - Unifying and USB after patch: e8-ce-cd-45 Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230302130117.3975-2-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
7ad1fe0d |
|
02-Mar-2023 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Don't use the USB serial for USB devices For devices that support the 0x0003 feature (Device Information) version 4, set the serial based on the output of that feature, rather than relying on the usbhid code setting the USB serial. This should allow the serial when connected through USB to (nearly) match the one when connected through a unifying receiver. For example, on the serials on a G903 wired/wireless mouse: - Unifying: 4067-e8-ce-cd-45 - USB before patch: 017C385C3837 - USB after patch: c086-e8-ce-cd-45 Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230302130117.3975-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
db50f7a3 |
|
28-Feb-2023 |
Rafał Szalecki <perexist7@gmail.com> |
HID: logitech-hidpp: Add support for Logitech MX Master 3S mouse Add signature for the Logitech MX Master 3S mouse over Bluetooth. Signed-off-by: Rafał Szalecki <perexist7@gmail.com> Reviewed-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
1b136aeb |
|
09-Feb-2023 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Add myself to authors As discussed with HID maintainer Benjamin Tissoires, add myself to the authors list and MAINTAINERS file. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230209154916.462158-2-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
586e8fed |
|
09-Feb-2023 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Retry commands when device is busy Handle the busy error coming from the device or receiver. The documentation says a busy error can be returned when: " Device (or receiver) cannot answer immediately to this request for any reason i.e: - already processing a request from the same or another SW - pipe full " Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230209154916.462158-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
a47a3b7a |
|
06-Feb-2023 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Add more debug statements This should help us figure out some hairy problems with some devices. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230206221256.129198-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
e8ab7a10 |
|
07-Feb-2023 |
Walt Holman <waltholman09@gmail.com> |
HID: Add support for Logitech G923 Xbox Edition steering wheel We get the same level of features as the regular G920. Signed-off-by: Walt Holman <waltholman09@gmail.com> Link: https://lore.kernel.org/r/20230207195051.16373-1-waltholman09@gmail.com Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
3ab1c27f |
|
03-Apr-2022 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Add Signature M650 Add support for HID++ over Bluetooth for the Logitech Signature M650 mouse. It comes with a dongle but can also be used over Bluetooth without one. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20220404100311.3304-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
d83956c8 |
|
25-Jan-2023 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Remove HIDPP_QUIRK_NO_HIDINPUT quirk HIDPP_QUIRK_NO_HIDINPUT isn't used by any devices but still happens to work as HIDPP_QUIRK_DELAYED_INIT is defined to the same value. Remove HIDPP_QUIRK_NO_HIDINPUT and use HIDPP_QUIRK_DELAYED_INIT everywhere instead. Tested on a T650 which requires that quirk, and a number of unifying and Bluetooth devices that don't. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230125121723.3122-2-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
498ba206 |
|
25-Jan-2023 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Don't restart communication if not necessary Don't stop and restart communication with the device unless we need to modify the connect flags used because of a device quirk. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230125121723.3122-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
43551d9b |
|
07-Dec-2022 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Add constants for HID++ 2.0 error codes Add constants for HID++ 2.0 error codes listed in "Protocol HID++2.0 essential features" chapter, page 3, in logitech_hidpp_2.0_specification_draft_2012-06-04.pdf Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20221207100033.64095-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
cae253d6 |
|
20-Dec-2022 |
Bastien Nocera <hadess@hadess.net> |
Revert "HID: logitech-hidpp: add a module parameter to keep firmware gestures" Now that we're in 2022, and the majority of desktop environments can and should support touchpad gestures through libinput, remove the legacy module parameter that made it possible to use gestures implemented in firmware. This will eventually allow simplifying the driver's initialisation code. This reverts commit 9188dbaed68a4b23dc96eba165265c08caa7dc2a. Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20221220154345.474596-1-hadess@hadess.net
|
#
719acb4d |
|
16-Jan-2023 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Hard-code HID++ 1.0 fast scroll support HID++ 1.0 devices only export whether Fast Scrolling is enabled, not whether they are capable of it. Reinstate the original quirks for the 3 supported mice so fast scrolling works again on those devices. Fixes: 908d325e1665 ("HID: logitech-hidpp: Detect hi-res scrolling support") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216903 Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20230116130937.391441-1-hadess@hadess.net
|
#
690eb7de |
|
03-Feb-2023 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech: Disable hi-res scrolling on USB On some Logitech mice, such as the G903, and possibly the G403, the HID events are generated on a different interface to the HID++ one. If we enable hi-res through the HID++ interface, the HID interface wouldn't know anything about it, and handle the events as if they were regular scroll events, making the mouse unusable. Disable hi-res scrolling on those devices until we implement scroll events through HID++. Signed-off-by: Bastien Nocera <hadess@hadess.net> Tested-by: Tobias Klausmann <klausman@schwarzvogel.de> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216885 Fixes: 908d325e1665 ("HID: logitech-hidpp: Detect hi-res scrolling support") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230203101800.139380-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
0e13e7b4 |
|
15-Dec-2022 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Guard FF init code against non-USB devices The Force Feedback code assumes that all the devices passed to it will be USB devices, but that might not be the case for emulated devices. Guard against a crash by checking the device type before poking at USB properties. Cc: stable@vger.kernel.org # v5.16+ Reported-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20221215154416.111704-1-hadess@hadess.net
|
#
8b7e5840 |
|
11-Nov-2022 |
Andreas Bergmeier <abergmeier@gmx.net> |
HID: logitech HID++: Send SwID in GetProtocolVersion According to docs a SwID should be sent for GetProtocolVersion. > 0x10.DeviceIndex.0x00.0x1n where n is SwID. Signed-off-by: Andreas Bergmeier <abergmeier@gmx.net> Reviewed-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
a9d9e46c |
|
07-Dec-2022 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
Revert "HID: logitech-hidpp: Enable HID++ for all the Logitech Bluetooth devices" This reverts commit 532223c8ac57605a10e46dc0ab23dcf01c9acb43. As reported in [0], hid-logitech-hidpp now binds on all bluetooth mice, but there are corner cases where hid-logitech-hidpp just gives up on the mouse. This leads the end user with a dead mouse. Given that we are at -rc8, we are definitively too late to find a proper fix. We already identified 2 issues less than 24 hours after the bug report. One in that ->match() was never designed to be used anywhere else than in hid-generic, and the other that hid-logitech-hidpp has corner cases where it gives up on devices it is not supposed to. So we have no choice but postpone this patch to the next kernel release. [0] https://lore.kernel.org/linux-input/CAJZ5v0g-_o4AqMgNwihCb0jrwrcJZfRrX=jv8aH54WNKO7QB8A@mail.gmail.com/ Reported-by: Rafael J . Wysocki <rjw@rjwysocki.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
40f2432b |
|
07-Dec-2022 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
Revert "HID: logitech-hidpp: Remove special-casing of Bluetooth devices" This reverts commit 8544c812e43ab7bdf40458411b83987b8cba924d. We need to revert commit 532223c8ac57 ("HID: logitech-hidpp: Enable HID++ for all the Logitech Bluetooth devices") because that commit might make hid-logitech-hidpp bind on mice that are not well enough supported by hid-logitech-hidpp, and the end result is that the probe of those mice is now returning -ENODEV, leaving the end user with a dead mouse. Given that commit 8544c812e43a ("HID: logitech-hidpp: Remove special-casing of Bluetooth devices") is a direct dependency of 532223c8ac57, revert it too. Note that this also adapt according to commit 908d325e1665 ("HID: logitech-hidpp: Detect hi-res scrolling support") to re-add support of the devices that were removed from that commit too. I have locally an MX Master and I tested this device with that revert, ensuring we still have high-res scrolling. Reported-by: Rafael J . Wysocki <rjw@rjwysocki.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
98d67f25 |
|
11-Aug-2022 |
Hangyu Hua <hbh25y@gmail.com> |
hid: hid-logitech-hidpp: avoid unnecessary assignments in hidpp_connect_event hidpp->delayed_input can't be assigned to an object that already call input_free_device when input_register_device fails. Fixes: c39e3d5fc9dd ("HID: logitech-hidpp: late bind the input device on wireless connection") Signed-off-by: Hangyu Hua <hbh25y@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20220812025515.19467-1-hbh25y@gmail.com
|
#
908d325e |
|
14-Sep-2022 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Detect hi-res scrolling support Rather than relying on a never-ending stream of patches for quirks. This change will detect whether HID++ 1.0 hi-res scroll, HID++ 2.0 hi-res scroll or HID++ 2.0 hi-res scroll wheel is supported, and enable the feature without the need for quirks. Tested on a Logitech M705 mouse that was unsupported before this change. [ 9.365324] logitech-hidpp-device 0003:046D:406D.0006: input,hidraw3: USB HID v1.11 Mouse [Logitech M705] on usb-0000:00:14.0-4/input2:3 [ 57.472434] logitech-hidpp-device 0003:046D:406D.0006: HID++ 4.5 device connected. [ 57.616429] logitech-hidpp-device 0003:046D:406D.0006: Detected HID++ 2.0 hi-res scroll wheel [ 57.712424] logitech-hidpp-device 0003:046D:406D.0006: wheel multiplier = 8 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216480 Signed-off-by: Bastien Nocera <hadess@hadess.net> Reviewed-by: Harry Cutts <hcutts@chromium.org> Tested-by: Peter F. Patel-Schneider <pfpschneider@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20220914132146.6435-1-hadess@hadess.net
|
#
0799617f |
|
30-Aug-2022 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Remove hard-coded "Sw. Id." for HID++ 2.0 commands Some HID++ 2.0 commands had correctly set a non-zero software identifier directly as part of their function identifiers, but it's more correct to define the function identifier and the software identifier separately before combined them when the command is sent. As this is now done in the previous commit, remove the hard-coded 0x1 software identifiers in the function definitions. Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
f7b7393c |
|
30-Aug-2022 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Fix "Sw. Id." for HID++ 2.0 commands Always set a non-zero "Sw. Id." in the lower nibble of the Function/ASE and Software Identifier byte in HID++ 2.0 commands. As per the "Protocol HID++2.0 essential features" section in https://lekensteyn.nl/files/logitech/logitech_hidpp_2.0_specification_draft_2012-06-04.pdf " Software identifier (4 bits, unsigned) A number uniquely defining the software that sends a request. The firmware must copy the software identifier in the response but does not use it in any other ways. 0 Do not use (allows to distinguish a notification from a response). " Link: https://bugzilla.kernel.org/show_bug.cgi?id=215699 Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
8544c812 |
|
30-Aug-2022 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Remove special-casing of Bluetooth devices Now that all the Logitech Bluetooth devices are probed for HID++ support, remove the handling of those 2 devices without any quirks, as they're duplicates. Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
532223c8 |
|
30-Aug-2022 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Enable HID++ for all the Logitech Bluetooth devices Probe for HID++ support over Bluetooth for all the Logitech Bluetooth devices. As Logitech doesn't have a list of Bluetooth devices that support HID++ over Bluetooth, probe every device. The HID++ driver will fall back to plain HID if the device does not support HID++, or to a another device-specific driver if it is part of the unhandled_hidpp_devices array, used in the match function. Note that this change might cause upower to export 2 batteries for certain Bluetooth LE devices which export their battery information through the Bluetooth BATT profile. This particular bug is tracked at: https://gitlab.freedesktop.org/upower/upower/-/issues/166 Tested with a Logitech Signature M650 mouse, over Bluetooth Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
6431fd01 |
|
05-Jun-2022 |
Xiang wangx <wangxiang@cdjrlc.com> |
HID: logitech-hidpp: Fix syntax errors in comments Delete the redundant word 'in'. Signed-off-by: Xiang wangx <wangxiang@cdjrlc.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
b23cdfbd |
|
02-Aug-2021 |
Hamza Mahfooz <someguy@effective-light.com> |
HID: logitech-hidpp: battery: provide CAPACITY property for newer devices For devices that only support the BATTERY_VOLTAGE (0x1001) feature, UPower requires the additional information provided by this patch, to set them up. Signed-off-by: Hamza Mahfooz <someguy@effective-light.com> Reviewed-by: Filipe Laíns <lains@riseup.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
46dcd1cc |
|
23-Jul-2021 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
HID: logitech-hidpp: Use 'atomic_inc_return' instead of hand-writing it This function logs a warning if the workqueue gets too big. In order to save a few cycles, use 'atomic_inc_return()' instead of an 'atomic_inc()/atomic_read()' sequence. This axes a line of code and saves a 'atomic_read()' call. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> 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>
|
#
81c8bf91 |
|
07-May-2021 |
Tom Rix <trix@redhat.com> |
HID: logitech-hidpp: initialize level variable Static analysis reports this representative problem hid-logitech-hidpp.c:1356:23: warning: Assigned value is garbage or undefined hidpp->battery.level = level; ^ ~~~~~ In some cases, 'level' is never set in hidpp20_battery_map_status_voltage() Since level is not available on all hw, initialize level to unknown. Fixes: be281368f297 ("hid-logitech-hidpp: read battery voltage from newer devices") Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Filipe Laíns <lains@riseup.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
3f37fdcd |
|
26-Mar-2021 |
Lee Jones <lee.jones@linaro.org> |
HID: hid-logitech-hidpp: Fix conformant kernel-doc header and demote abuses Fixes the following W=1 kernel build warning(s): drivers/hid/hid-logitech-hidpp.c:275: warning: Function parameter or member 'hidpp' not described in 'hidpp_send_message_sync' drivers/hid/hid-logitech-hidpp.c:275: warning: Function parameter or member 'message' not described in 'hidpp_send_message_sync' drivers/hid/hid-logitech-hidpp.c:275: warning: Function parameter or member 'response' not described in 'hidpp_send_message_sync' drivers/hid/hid-logitech-hidpp.c:275: warning: expecting prototype for and something else(). Prototype was for hidpp_send_message_sync() instead drivers/hid/hid-logitech-hidpp.c:427: warning: wrong kernel-doc identifier on line: drivers/hid/hid-logitech-hidpp.c:470: warning: Function parameter or member 'input_dev' not described in 'hidpp_scroll_counter_handle_scroll' drivers/hid/hid-logitech-hidpp.c:1894: warning: Function parameter or member 'hidpp' not described in 'hidpp_touchpad_fw_items_set' drivers/hid/hid-logitech-hidpp.c:1894: warning: Function parameter or member 'feature_index' not described in 'hidpp_touchpad_fw_items_set' drivers/hid/hid-logitech-hidpp.c:1894: warning: Function parameter or member 'items' not described in 'hidpp_touchpad_fw_items_set' drivers/hid/hid-logitech-hidpp.c:1894: warning: expecting prototype for send a set state command to the device by reading the current items(). Prototype was for hidpp_touchpad_fw_items_set() instead Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: Henrik Rydberg <rydberg@bitmath.org> Cc: Lopez Casado <nlopezcasad@logitech.com> Cc: linux-input@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
e037acf0 |
|
04-Jan-2021 |
Filipe Laíns <lains@archlinux.org> |
HID: logitech-hidpp: add support for Unified Battery (1004) feature This new feature present in new devices replaces the old Battery Level Status (0x1000) feature. It keeps essentially the same information for levels (reporting critical, low, good and full) but makes these levels optional, the device exports a capability setting which describes which levels it supports. In addition to this, there is an optional state_of_charge paramenter that exports the battery percentage. This patch adds support for this new feature. There were some implementation choices, as described below and in the code. If the device supports the state_of_charge parameter, we will just export the battery percentage and not the levels, which the device might still support. Since this feature can co-exist with the Battery Voltage (0x1001) feature and we currently only support one battery feature, I changed the battery feature discovery to try to use 0x1000 and 0x1004 first and only then 0x1001, the battery voltage feature. In the future we could uncouple this and make the battery feature co-exists with 0x1000 and 0x1004, allowing the device to export voltage information in addition to the battery percentage or level. I tested this patch with a MX Anywhere 3, which supports the new feature. Since I don't have any device that doesn't support the state_of_charge parameter of this feature, I forced the MX Anywhere 3 to use the level information, instead of battery percentage, to test that part of the implementation. I also tested with a MX Master 3, which supports the Battery Level Status (0x1000) feature, and a G703 Hero, which supports the Battery Voltage (0x1001) feature, to make sure nothing broke there. [jkosina@suse.cz: fix comment] Signed-off-by: Filipe Laíns <lains@archlinux.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
7de843db |
|
10-Jan-2021 |
Nicholas Miell <nmiell@gmail.com> |
HID: logitech-hidpp: Add product ID for MX Ergo in Bluetooth mode The Logitech MX Ergo trackball supports HID++ 4.5 over Bluetooth. Add its product ID to the table so we can get battery monitoring support. (The hid-logitech-hidpp driver already recognizes it when connected via a Unifying Receiver.) [jkosina@suse.cz: fix whitespace damage] Signed-off-by: Nicholas Miell <nmiell@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
ba876cdc |
|
19-Nov-2020 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Add hid_device_id for V470 bluetooth mouse The Logitech V470 bluetooth mouse supports HID++-1.0 over bluetooth, add its id to the hidpp driver so that it handles it. This enables battery monitoring support. Note this mouse does not support hi-resolution scroll-wheel events. Signed-off-by: Hans de Goede <hdegoede@redhat.com> 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>
|
#
c27168a0 |
|
02-Nov-2020 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Add HIDPP_CONSUMER_VENDOR_KEYS quirk for the Dinovo Edge Like the MX5000 and MX5500 quad/bluetooth keyboards the Dinovo Edge also needs the HIDPP_CONSUMER_VENDOR_KEYS quirk for some special keys to work. Specifically without this the "Phone" and the 'A' - 'D' Smart Keys do not send any events. In addition to fixing these keys not sending any events, adding the Bluetooth match, so that hid-logitech-hidpp is used instead of the generic HID driver, also adds battery monitoring support when the keyboard is connected over Bluetooth. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
b59f38db |
|
21-Oct-2020 |
Harry Cutts <hcutts@chromium.org> |
HID: logitech-hidpp: Add PID for MX Anywhere 2 It seems that the PID 0x4072 was missing from the list Logitech gave me for this mouse, as I found one with it in the wild (with which I tested this patch). Fixes: 4435ff2f09a2 ("HID: logitech: Enable high-resolution scrolling on Logitech mice") Signed-off-by: Harry Cutts <hcutts@chromium.org> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
e13762ab |
|
05-Jul-2020 |
Maciej S. Szmigiero <mail@maciej.szmigiero.name> |
HID: logitech-hidpp: avoid repeated "multiplier = " log messages These messages appear each time the mouse wakes from sleep, in my case (Logitech M705), every minute or so. Let's downgrade them to the "debug" level so they don't fill the kernel log by default. While we are at it, let's make clear that this is a wheel multiplier (and not, for example, XY movement multiplier). Fixes: 4435ff2f09a2 ("HID: logitech: Enable high-resolution scrolling on Logitech mice") Cc: stable@vger.kernel.org Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name> Reviewed-by: Harry Cutts <hcutts@chromium.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>
|
#
4ab2bb3c |
|
11-Jan-2020 |
Filipe Laíns <lains@archlinux.org> |
HID: logitech-hidpp: BatteryVoltage: only read chargeStatus if extPower is active In the HID++ 2.0 function getBatteryInfo() from the BatteryVoltage (0x1001) feature, chargeStatus is only valid if extPower is active. Previously we were ignoring extPower, which resulted in wrong values. Example: With an unplugged mouse $ cat /sys/class/power_supply/hidpp_battery_0/status Charging This patch fixes that, it also renames charge_sts to flags as charge_sts can be confused with chargeStatus from the spec. Spec: +--------+-------------------------------------------------------------------------+ | byte | 2 | +--------+--------------+------------+------------+----------+----------+----------+ | bit | 0..2 | 3 | 4 | 5 | 6 | 7 | +--------+--------------+------------+------------+----------+----------+----------+ | buffer | chargeStatus | fastCharge | slowCharge | critical | (unused) | extPower | +--------+--------------+------------+------------+----------+----------+----------+ Table 1 - battery voltage (0x1001), getBatteryInfo() (ASE 0), 3rd byte +-------+--------------------------------------+ | value | meaning | +-------+--------------------------------------+ | 0 | Charging | +-------+--------------------------------------+ | 1 | End of charge (100% charged) | +-------+--------------------------------------+ | 2 | Charge stopped (any "normal" reason) | +-------+--------------------------------------+ | 7 | Hardware error | +-------+--------------------------------------+ Table 2 - chargeStatus value Signed-off-by: Filipe Laíns <lains@archlinux.org> Tested-by: Pedro Vanzella <pedro@pedrovanzella.com> Reviewed-by: Pedro Vanzella <pedro@pedrovanzella.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
8f2828d7 |
|
26-Dec-2019 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
HID: logitech-hidpp: avoid duplicate error handling code in 'hidpp_probe()' 'hid_hw_stop()' is already in the error handling path when branching to the 'hid_hw_open_fail' label. There is no point in calling it twice, so remove one. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
be281368 |
|
26-Oct-2019 |
Pedro Vanzella <pedro@pedrovanzella.com> |
hid-logitech-hidpp: read battery voltage from newer devices Newer Logitech mice report their battery voltage through feature 0x1001 instead of the battery levels through feature 0x1000. When the device is brought up and we try to query the battery, figure out if it supports the old or the new feature. If it supports the new feature, record the feature index and read the battery voltage and its charge status. The device will respond with three bytes: the first two are its voltage, and the last one is a bitset, reporting if the battery is charging, fast or slow, in critical level or discharging. If everything went correctly, record the fact that we're capable of querying battery voltage. Note that the protocol only gives us the current voltage in mV. We store that as-is, but when queried, we report it in uV as expected by sysfs. Like we do for other ways of interacting with the battery for other devices, refresh the battery status and notify the power supply subsystem of the changes in voltage and status. Since there are no known devices which implement both the old and the new battery feature, we make sure to try the newer feature first and only fall back to the old one if that fails. Signed-off-by: Pedro Vanzella <pedro@pedrovanzella.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
04bd6817 |
|
25-Oct-2019 |
Adrian Freund <adrian@freund.io> |
HID: logitech: Add MX Master 3 Mouse This patch adds support for the Logitech MX Master 3 Mouse using the Logitech Unifying Receiver and Bluetooth LE. Signed-off-by: Adrian Freund <adrian@freund.io> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
0da0a63b |
|
27-Oct-2019 |
Mazin Rezk <mnrzk@protonmail.com> |
HID: logitech-hidpp: Support WirelessDeviceStatus connect events This patch allows hidpp_report_is_connect_event to support WirelessDeviceStatus connect events. The WirelessDeviceStatus feature index is stored in hidpp_device when probed. The connect event's fap feature_index is compared against it if the device supports it. Signed-off-by: Mazin Rezk <mnrzk@protonmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
c2a93271 |
|
27-Oct-2019 |
Mazin Rezk <mnrzk@protonmail.com> |
HID: logitech-hidpp: Support translations from short to long reports This patch allows short reports to be translated into long reports. hidpp_validate_device now returns a u8 instead of a bool which represents the supported reports. The corresponding bits (i.e. HIDPP_REPORT_*_SUPPORTED) are set if an HID++ report is supported. If a short report is being sent and the device does not support it, it is instead sent as a long report. This patch also introduces support for the MX Master (b01e and b012). Signed-off-by: Mazin Rezk <mnrzk@protonmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
61005d65 |
|
14-Nov-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Silence intermittent get_battery_capacity errors My Logitech M185 (PID:4038) 2.4 GHz wireless HID++ mouse is causing intermittent errors like these in the log: [11091.034857] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09 [12388.031260] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09 [16613.718543] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09 [23529.938728] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09 We are already silencing error-code 0x09 (HIDPP_ERROR_RESOURCE_ERROR) errors in other places, lets do the same in hidpp20_batterylevel_get_battery_capacity to remove these harmless, but scary looking errors from the dmesg output. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
08c453f6 |
|
17-Oct-2019 |
Andrey Smirnov <andrew.smirnov@gmail.com> |
HID: logitech-hidpp: do all FF cleanup in hidpp_ff_destroy() All of the FF-related resources belong to corresponding FF device, so they should be freed as a part of hidpp_ff_destroy() to avoid potential race condidions. Fixes: ff21a635dd1a ("HID: logitech-hidpp: Force feedback support for the Logitech G920") Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: Henrik Rydberg <rydberg@bitmath.org> Cc: Pierre-Loup A. Griffais <pgriffais@valvesoftware.com> Cc: Austin Palmer <austinp@valvesoftware.com> Cc: linux-input@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # 5.2+ Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
905d754c |
|
17-Oct-2019 |
Andrey Smirnov <andrew.smirnov@gmail.com> |
HID: logitech-hidpp: rework device validation G920 device only advertises REPORT_ID_HIDPP_LONG and REPORT_ID_HIDPP_VERY_LONG in its HID report descriptor, so querying for REPORT_ID_HIDPP_SHORT with optional=false will always fail and prevent G920 to be recognized as a valid HID++ device. To fix this and improve some other aspects, modify hidpp_validate_device() as follows: - Inline the code of hidpp_validate_report() to simplify distingushing between non-present and invalid report descriptors - Drop the check for id >= HID_MAX_IDS || id < 0 since all of our IDs are static and known to satisfy that at compile time - Change the algorithms to check all possible report types (including very long report) and deem the device as a valid HID++ device if it supports at least one - Treat invalid report length as a hard stop for the validation algorithm, meaning that if any of the supported reports has invalid length we assume the worst and treat the device as a generic HID device. - Fold initialization of hidpp->very_long_report_length into hidpp_validate_device() since it already fetches very long report length and validates its value Fixes: fe3ee1ec007b ("HID: logitech-hidpp: allow non HID++ devices to be handled by this module") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204191 Reported-by: Sam Bazely <sambazley@fastmail.com> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: Henrik Rydberg <rydberg@bitmath.org> Cc: Pierre-Loup A. Griffais <pgriffais@valvesoftware.com> Cc: Austin Palmer <austinp@valvesoftware.com> Cc: linux-input@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # 5.2+ Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
abdd3d0b |
|
17-Oct-2019 |
Andrey Smirnov <andrew.smirnov@gmail.com> |
HID: logitech-hidpp: split g920_get_config() Original version of g920_get_config() contained two kind of actions: 1. Device specific communication to query/set some parameters which requires active communication channel with the device, or, put in other way, for the call to be sandwiched between hid_device_io_start() and hid_device_io_stop(). 2. Input subsystem specific FF controller initialization which, in order to access a valid 'struct hid_input' via 'hid->inputs.next', requires claimed hidinput which means be executed after the call to hid_hw_start() with connect_mask containing HID_CONNECT_HIDINPUT. Location of g920_get_config() can only fulfill requirements for #1 and not #2, which might result in following backtrace: [ 88.312258] logitech-hidpp-device 0003:046D:C262.0005: HID++ 4.2 device connected. [ 88.320298] BUG: kernel NULL pointer dereference, address: 0000000000000018 [ 88.320304] #PF: supervisor read access in kernel mode [ 88.320307] #PF: error_code(0x0000) - not-present page [ 88.320309] PGD 0 P4D 0 [ 88.320315] Oops: 0000 [#1] SMP PTI [ 88.320320] CPU: 1 PID: 3080 Comm: systemd-udevd Not tainted 5.4.0-rc1+ #31 [ 88.320322] Hardware name: Apple Inc. MacBookPro11,1/Mac-189A3D4F975D5FFC, BIOS 149.0.0.0.0 09/17/2018 [ 88.320334] RIP: 0010:hidpp_probe+0x61f/0x948 [hid_logitech_hidpp] [ 88.320338] Code: 81 00 00 48 89 ef e8 f0 d6 ff ff 41 89 c6 85 c0 75 b5 0f b6 44 24 28 48 8b 5d 00 88 44 24 1e 89 44 24 0c 48 8b 83 18 1c 00 00 <48> 8b 48 18 48 8b 83 10 19 00 00 48 8b 40 40 48 89 0c 24 0f b7 80 [ 88.320341] RSP: 0018:ffffb0a6824aba68 EFLAGS: 00010246 [ 88.320345] RAX: 0000000000000000 RBX: ffff93a50756e000 RCX: 0000000000010408 [ 88.320347] RDX: 0000000000000000 RSI: ffff93a51f0ad0a0 RDI: 000000000002d0a0 [ 88.320350] RBP: ffff93a50416da28 R08: ffff93a50416da70 R09: ffff93a50416da70 [ 88.320352] R10: 000000148ae9e60c R11: 00000000000f1525 R12: ffff93a50756e000 [ 88.320354] R13: ffff93a50756f8d0 R14: 0000000000000000 R15: ffff93a50756fc38 [ 88.320358] FS: 00007f8d8c1e0940(0000) GS:ffff93a51f080000(0000) knlGS:0000000000000000 [ 88.320361] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.320363] CR2: 0000000000000018 CR3: 00000003996d8003 CR4: 00000000001606e0 [ 88.320366] Call Trace: [ 88.320377] ? _cond_resched+0x15/0x30 [ 88.320387] ? create_pinctrl+0x2f/0x3c0 [ 88.320393] ? kernfs_link_sibling+0x94/0xe0 [ 88.320398] ? _cond_resched+0x15/0x30 [ 88.320402] ? kernfs_activate+0x5f/0x80 [ 88.320406] ? kernfs_add_one+0xe2/0x130 [ 88.320411] hid_device_probe+0x106/0x170 [ 88.320419] really_probe+0x147/0x3c0 [ 88.320424] driver_probe_device+0xb6/0x100 [ 88.320428] device_driver_attach+0x53/0x60 [ 88.320433] __driver_attach+0x8a/0x150 [ 88.320437] ? device_driver_attach+0x60/0x60 [ 88.320440] bus_for_each_dev+0x78/0xc0 [ 88.320445] bus_add_driver+0x14d/0x1f0 [ 88.320450] driver_register+0x6c/0xc0 [ 88.320453] ? 0xffffffffc0d67000 [ 88.320457] __hid_register_driver+0x4c/0x80 [ 88.320464] do_one_initcall+0x46/0x1f4 [ 88.320469] ? _cond_resched+0x15/0x30 [ 88.320474] ? kmem_cache_alloc_trace+0x162/0x220 [ 88.320481] ? do_init_module+0x23/0x230 [ 88.320486] do_init_module+0x5c/0x230 [ 88.320491] load_module+0x26e1/0x2990 [ 88.320502] ? ima_post_read_file+0xf0/0x100 [ 88.320508] ? __do_sys_finit_module+0xaa/0x110 [ 88.320512] __do_sys_finit_module+0xaa/0x110 [ 88.320520] do_syscall_64+0x5b/0x180 [ 88.320525] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 88.320528] RIP: 0033:0x7f8d8d1f01fd [ 88.320532] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 5b 8c 0c 00 f7 d8 64 89 01 48 [ 88.320535] RSP: 002b:00007ffefa3bb068 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 88.320539] RAX: ffffffffffffffda RBX: 000055922040cb40 RCX: 00007f8d8d1f01fd [ 88.320541] RDX: 0000000000000000 RSI: 00007f8d8ce4984d RDI: 0000000000000006 [ 88.320543] RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000007 [ 88.320545] R10: 0000000000000006 R11: 0000000000000246 R12: 00007f8d8ce4984d [ 88.320547] R13: 0000000000000000 R14: 000055922040efc0 R15: 000055922040cb40 [ 88.320551] Modules linked in: hid_logitech_hidpp(+) fuse rfcomm ccm xt_CHECKSUM xt_MASQUERADE bridge stp llc nf_nat_tftp nf_conntrack_tftp nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat tun iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables cmac bnep sunrpc dm_crypt nls_utf8 hfsplus intel_rapl_msr intel_rapl_common ath9k_htc ath9k_common x86_pkg_temp_thermal intel_powerclamp b43 ath9k_hw coretemp snd_hda_codec_hdmi cordic kvm_intel snd_hda_codec_cirrus mac80211 snd_hda_codec_generic ledtrig_audio kvm snd_hda_intel snd_intel_nhlt irqbypass snd_hda_codec btusb btrtl snd_hda_core ath btbcm ssb snd_hwdep btintel snd_seq crct10dif_pclmul iTCO_wdt snd_seq_device crc32_pclmul bluetooth mmc_core iTCO_vendor_support joydev cfg80211 [ 88.320602] applesmc ghash_clmulni_intel ecdh_generic snd_pcm input_polldev intel_cstate ecc intel_uncore thunderbolt snd_timer i2c_i801 libarc4 rfkill intel_rapl_perf lpc_ich mei_me pcspkr bcm5974 snd bcma mei soundcore acpi_als sbs kfifo_buf sbshc industrialio apple_bl i915 i2c_algo_bit drm_kms_helper drm uas crc32c_intel usb_storage video hid_apple [ 88.320630] CR2: 0000000000000018 [ 88.320633] ---[ end trace 933491c8a4fadeb7 ]--- [ 88.320642] RIP: 0010:hidpp_probe+0x61f/0x948 [hid_logitech_hidpp] [ 88.320645] Code: 81 00 00 48 89 ef e8 f0 d6 ff ff 41 89 c6 85 c0 75 b5 0f b6 44 24 28 48 8b 5d 00 88 44 24 1e 89 44 24 0c 48 8b 83 18 1c 00 00 <48> 8b 48 18 48 8b 83 10 19 00 00 48 8b 40 40 48 89 0c 24 0f b7 80 [ 88.320647] RSP: 0018:ffffb0a6824aba68 EFLAGS: 00010246 [ 88.320650] RAX: 0000000000000000 RBX: ffff93a50756e000 RCX: 0000000000010408 [ 88.320652] RDX: 0000000000000000 RSI: ffff93a51f0ad0a0 RDI: 000000000002d0a0 [ 88.320655] RBP: ffff93a50416da28 R08: ffff93a50416da70 R09: ffff93a50416da70 [ 88.320657] R10: 000000148ae9e60c R11: 00000000000f1525 R12: ffff93a50756e000 [ 88.320659] R13: ffff93a50756f8d0 R14: 0000000000000000 R15: ffff93a50756fc38 [ 88.320662] FS: 00007f8d8c1e0940(0000) GS:ffff93a51f080000(0000) knlGS:0000000000000000 [ 88.320664] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.320667] CR2: 0000000000000018 CR3: 00000003996d8003 CR4: 00000000001606e0 To solve this issue: 1. Split g920_get_config() such that all of the device specific communication remains a part of the function and input subsystem initialization bits go to hidpp_ff_init() 2. Move call to hidpp_ff_init() from being a part of g920_get_config() to be the last step of .probe(), right after a call to hid_hw_start() with connect_mask containing HID_CONNECT_HIDINPUT. Fixes: 91cf9a98ae41 ("HID: logitech-hidpp: make .probe usbhid capable") Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Tested-by: Sam Bazley <sambazley@fastmail.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: Henrik Rydberg <rydberg@bitmath.org> Cc: Pierre-Loup A. Griffais <pgriffais@valvesoftware.com> Cc: Austin Palmer <austinp@valvesoftware.com> Cc: linux-input@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # 5.2+ Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
d9d4b1e4 |
|
03-Oct-2019 |
Alan Stern <stern@rowland.harvard.edu> |
HID: Fix assumption that devices have inputs The syzbot fuzzer found a slab-out-of-bounds write bug in the hid-gaff driver. The problem is caused by the driver's assumption that the device must have an input report. While this will be true for all normal HID input devices, a suitably malicious device can violate the assumption. The same assumption is present in over a dozen other HID drivers. This patch fixes them by checking that the list of hid_inputs for the hid_device is nonempty before allowing it to be used. Reported-and-tested-by: syzbot+403741a091bf41d4ae79@syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
a3384b8d |
|
13-Aug-2019 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: remove support for the G700 over USB The G700 suffers from the same issue than the G502: when plugging it in, the driver tries to contact it but it fails. This timeout is problematic as it introduce a delay in the boot, and having only the mouse event node means that the hardware macros keys can not be relayed to the userspace. Link: https://github.com/libratbag/libratbag/issues/797 Fixes: 91cf9a98ae41 ("HID: logitech-hidpp: make .probe usbhid capable") Cc: stable@vger.kernel.org # v5.2 Reviewed-by: Filipe Laíns <lains@archlinux.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
addf3382 |
|
13-Aug-2019 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
Revert "HID: logitech-hidpp: add USB PID for a few more supported mice" This partially reverts commit 27fc32fd9417968a459d43d9a7c50fd423d53eb9. It turns out that the G502 has some issues with hid-logitech-hidpp: when plugging it in, the driver tries to contact it but it fails. So the driver bails out leaving only the mouse event node available. This timeout is problematic as it introduce a delay in the boot, and having only the mouse event node means that the hardware macros keys can not be relayed to the userspace. Filipe and I just gave a shot at the following devices: G403 Wireless (0xC082) G703 (0xC087) G703 Hero (0xC090) G903 (0xC086) G903 Hero (0xC091) G Pro (0xC088) Reverting the devices we are not sure that works flawlessly. Reviewed-by: Filipe Laíns <lains@archlinux.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
27fc32fd |
|
16-Jul-2019 |
Filipe Laíns <lains@archlinux.org> |
HID: logitech-hidpp: add USB PID for a few more supported mice Add more device IDs to logitech-hidpp driver. Signed-off-by: Filipe Laíns <lains@archlinux.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
b886d83c |
|
01-Jun-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 441 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 as published by the free software foundation version 2 of the license extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 315 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Armijn Hemel <armijn@tjaldur.nl> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190115.503150771@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2409877d |
|
11-May-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: Add support for the S510 remote control The S510 remote-control shows up as a second keyboard (keypad) on the receiver. It has a scroll-wheel, which normally sends wheel event originating from the mouse's evdev node. Add a HIDPP_QUIRK_KBD_SCROLL_WHEEL quirk for it, so that the wheel events properly originate from the evdev node of the remote control itself. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
a96a8a57 |
|
10-May-2019 |
Colin Ian King <colin.king@canonical.com> |
HID: logitech-hidpp: HID: make const array consumer_rdesc_start static Don't populate the array consumer_rdesc_start on the stack but instead make it static. Makes the object code smaller by 88 bytes. Before: text data bss dec hex filename 59155 9840 448 69443 10f43 drivers/hid/hid-logitech-hidpp.o After: text data bss dec hex filename 59003 9904 448 69355 10eeb drivers/hid/hid-logitech-hidpp.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>
|
#
ced2c0c5 |
|
28-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: add support for the MX5500 keyboard The MX5500 keyboard needs the HIDPP_CONSUMER_VENDOR_KEYS quirk to report events for the 'A' - 'D' Smart Keys and for the "Photo Gallery" and "Gadgets" keys. In addition to this adding the Bluetooth match, so that hid-logitech-hidpp is used instead of the generic HID driver, also adds battery monitoring support when the keyboard is connected over Bluetooth. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
42bc4f31 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: add support for HID++ 1.0 consumer keys reports All Logitech 27 MHz keyboards and also the MX5000 bluetooth keyboard use Logitech custom usages of 0x10xx in the consumer page. The descriptor for the consumer input-report only declares usages up to 652, so we end up dropping all the input-reports reporting 0x10xx usages without reporting events for these to userspace. This commit adds a descriptor_fixup function for this which changes the usage and logical maximum to 0x107f. Mapping these usages to something other then KEY_UNKNOWN is left to userspace (hwdb). Note: 1. The old descriptor_fixup for this in hid-lg.c used a maximimum of 0x104d this is not high enough, the S520 keyboard battery key sends 0x106f. 2. The descriptor_fixup is flexible so that it works with both the kbd- desc. passed by the logitech-dj code and with bluetooth descriptors. The descriptor_fixup makes most keys work on 27 MHz keyboards, but it is not enough to get all keys to work on 27 MHz keyboards and just the fixup is not enough to get the MX5000 to generate 0x10xx events: 1) The LX501 and MX3000 27 MHz kbds both have a button labelled "media" (called "Media Player" by SetPoint) and a button with a remote-control symbol ("Media Life" in SetPoint) which both send an identical consumer usage-page code (0x0183) making the 2 buttons indistinguishable, switching to HID++ 1.0 consumer keys reports makes the remote-control symbol button generate a 0x10xx Logitech specific code instead. 2) The MX5000 Bluetooth keyboard has 11 keys which report 0x10xx consumer page usages, but unlike 27 MHz devices which happily send 0x10xx codes in their normal consumer-page input-report, the MX5000 honors the maximum of 652 from its descriptor and sends a 0x0000 code (so release) whenever these keys are pressed. When switching to HID++ sub-id 0x03 HID++ 1.0 consumer keys reports these 0x10xx codes do get properly reported. This commit adds support for HID++ 1.0 consumer keys reports and enables this for all 27 MHz keyboards and for the MX5000. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
7457bc1b |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: add support for HID++ 1.0 extra mouse buttons reports Some mice have extra buttons which are only reported through HID++ 1.0 extra mouse buttons reports, this commit adds support for this and automatically enables this support for all 27 MHz mice. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
4a79bcc6 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: add support for HID++ 1.0 wheel reports Add a quirk for switching wheel event reporting to using the HID++ report for this. This has 2 advantages: 1) Without this tilting the scrollwheel left / right will send a scroll-lock + cursor-left/-right + scroll-lock key-sequence instead of hwheel events 2) The HID++ reports contain the device index instead of using the generic HID implementation, so this will make scroll-wheel events from the wheel on some keyboards be emitted by the right event node. 2. also fixes keyboard scroll-wheel events getting lost in the (mostly theoretical) case of there not being a mouse paired with the receiver. This commit enables this quirk for all 27Mhz mice, it cannot hurt to have it enabled and this avoids the need to keep adding more and more quirks for this. This has been tested in 5 different 27MHz mice, 3 of which have a wheel which can tilt. This commit also adds explicit quirks for 3 keyboards with a zoom-/scroll- wheel. The MX3000 keyboard scroll-wheel can also tilt. I've defined aliases to the new HIDPP_QUIRK_HIDPP_WHEELS for this, so that it is clear why the keyboard has the quirk and in case we want to handle the keyboard wheels and especially the keyboard zoom-wheels differently in the future. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
35839f77 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: make hidpp10_set_register_bit a bit more generic Make hidpp10_set_register_bit() take a mask and value for the register byte being changed, rather then making it only set a single bit. While at it also at defines for the bits which we will be using. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
0610430e |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: add input_device ptr to struct hidpp_device Most device-class specific code needs access to the input_device, instead of storing that in the class specific data-struct, simply store this into the hidpp_device struct itself. In case of the m560 this avoids the need for having private data at all and this will also avoid the need to add private data in some upcoming patches. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
d71b18f7 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: do not hardcode very long report length The HID++ spec says the following about the very long report length: "n Bytes, depends on HID++ collection declaration". Hardcoding this breaks talking to some HID++ devices over BlueTooth, since they declare only 45 bytes data for the very long report, rather then the hardcoded 63. This commit fixes this by getting the actual report length from the descriptors. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
754a3088 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: handle devices attached to 27MHz wireless receivers Logitech 27MHz devices are HID++ devices, so handle them in the hidpp driver, this enables battery monitoring on these devices (and more in follow-up patches). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
09637752 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: use RAP instead of FAP to get the protocol version According to the logitech_hidpp_2.0_specification_draft_2012-06-04.pdf doc: https://lekensteyn.nl/files/logitech/logitech_hidpp_2.0_specification_draft_2012-06-04.pdf We should use a register-access-protocol request using the short input / output report ids. This is necessary because 27MHz HID++ receivers have a max-packetsize on their HIP++ endpoint of 8, so they cannot support long reports. Using a feature-access-protocol request (which is always long or very-long) with these will cause a timeout error, followed by the hidpp driver treating the device as not being HID++ capable. This commit fixes this by switching to using a rap request to get the protocol version. Besides being tested with a (046d:c517) 27MHz receiver with various 27MHz keyboards and mice, this has also been tested to not cause regressions on a non-unifying dual-HID++ nano receiver (046d:c534) with k270 and m185 HID++-2.0 devices connected and on a unifying/dj receiver (046d:c52b) with a HID++-2.0 Logitech Rechargeable Touchpad T650. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
e54abaf6 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: remove unused origin_is_hid_core function parameter All the various populate_input functions have an origin_is_hid_core function parameter, but none use it, remove it. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
205a2ab0 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: remove double assignment from __hidpp_send_report The hidpp variable is already initialized with hid_get_drvdata(hdev) when it is declared, drop the second no-op assignment. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
2ddf07f3 |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: do not make failure to get the name fatal With devices attached to a non-unifying 2.4GHz receiver we sometimes fail to get the name. This is not a fatal error, we can just continue with the original name. So instead of bailing out, continue with battery-initialization when this happens. This fixes the battery not getting registered when we fail to get the name. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
22bf6bde |
|
20-Apr-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: ignore very-short or empty names Some devices report an empty or very short name, in this case stick with the name generated by the logitech-dj code instead of overriding it with e.g. "Logitech ". Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
91cf9a98 |
|
20-Apr-2019 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: make .probe usbhid capable The current custom solution for the G920 is not the best because hid_hw_start() is not called at the end of the .probe(). It means that any configuration retrieved after the initial hid_hw_start would not be exposed to user space without races. We can simply force hid_hw_start to just enable the transport layer by not using a connect_mask. This way, we can have a common path between USB, Unifying and Bluetooth devices. With this change, we can now support the non DJ receivers for low end devices, which will allow us to fetch the actual names of the paired device (instead of 'Logitech Wireless Receiver') Tested with a M185 with the non unifying receiver, a T650 and many other unifying devices, and the T651 over Bluetooth. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
fe3ee1ec |
|
20-Apr-2019 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: allow non HID++ devices to be handled by this module On the gaming mice, there are 2 interfaces, one for the mouse and one for the macros. Better allow everybody to go through hid-logitech-hidpp than trying to be smarter. 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>
|
#
1f87b0cd |
|
22-Mar-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: change low battery level threshold from 31 to 30 percent According to hidpp20_batterylevel_get_battery_info my Logitech K270 keyboard reports only 2 battery levels. This matches with what I've seen after testing with batteries at varying level of fullness, it always reports either 5% or 30%. Windows reports "battery good" for the 30% level. I've captured an USB trace of Windows reading the battery and it is getting the same info as the Linux hidpp code gets. Now that Linux handles these devices as hidpp devices, it reports the battery as being low as it treats anything under 31% as low, this leads to the user constantly getting a "Keyboard battery is low" warning from GNOME3, which is very annoying. This commit fixes this by changing the low threshold to anything under 30%, which I assume is what Windows does. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
090760d4 |
|
22-Mar-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: remove hidpp_is_connected() Remove the hidpp_is_connected() function wrapper, and have the callers directly call hidpp_root_get_protocol_version() instead. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
9576af6a |
|
22-Mar-2019 |
Hans de Goede <hdegoede@redhat.com> |
HID: logitech-hidpp: simplify printing of HID++ version Simply always print the HID++ version on hidpp_root_get_protocol_version success. This also fixes the version not being printed when a HID++ device connected through a receiver is already connected when the hidpp driver is loaded. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
fd35759c |
|
19-Mar-2019 |
Peter Hutterer <peter.hutterer@who-t.net> |
HID: logitech: Handle 0 scroll events for the m560 hidpp_scroll_counter_handle_scroll() doesn't expect a 0-value scroll event, it gets interpreted as a negative scroll direction event. This can cause scroll direction resets and thus broken scrolling. Fixes: 4435ff2f09a2fc ("HID: logitech: Enable high-resolution scrolling on Logitech mice") Cc: stable@vger.kernel.org # v5.0 Reported-and-tested-by: Aimo Metsälä <aimetsal@outlook.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
6c44b15e |
|
13-Mar-2019 |
Kangjie Lu <kjlu@umn.edu> |
HID: logitech: check the return value of create_singlethread_workqueue create_singlethread_workqueue may fail and return NULL. The fix checks if it is NULL to avoid NULL pointer dereference. Also, the fix moves the call of create_singlethread_workqueue earlier to avoid resource-release issues. Signed-off-by: Kangjie Lu <kjlu@umn.edu> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
16767229 |
|
04-Dec-2018 |
Harry Cutts <hcutts@chromium.org> |
HID: logitech: Use LDJ_DEVICE macro for existing Logitech mice Signed-off-by: Harry Cutts <hcutts@chromium.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Verified-by: Harry Cutts <hcutts@chromium.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
4435ff2f |
|
04-Dec-2018 |
Harry Cutts <hcutts@chromium.org> |
HID: logitech: Enable high-resolution scrolling on Logitech mice There are three features used by various Logitech mice for high-resolution scrolling: the scrolling acceleration bit in HID++ 1.0, and the x2120 and x2121 features in HID++ 2.0 and above. This patch supports all three, and uses the multiplier reported by the mouse for the HID++ 2.0+ features. The full list of product IDs of mice which support high-resolution scrolling was provided by Logitech, but the patch was tested using the following mice (using the Unifying receiver): * HID++ 1.0: Anywhere MX, Performance MX * x2120: M560 * x2121: MX Anywhere 2, MX Master 2S This patch is a combinations of the now-reverted commits 1ff2e1a44e0, d56ca9855bf9, 5fe2ccbef9d, 044ee89028 together with some extra bits for the directional and timeout-based reset. The previous patch series was in hid-input, it appears this remainder handling is logitech-specific and was moved to hid-logitech-hidpp.c and renamed accordingly. Signed-off-by: Harry Cutts <hcutts@chromium.org> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Verified-by: Harry Cutts <hcutts@chromium.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
95c3d002 |
|
04-Dec-2018 |
Harry Cutts <hcutts@chromium.org> |
HID: logitech: Add function to enable HID++ 1.0 "scrolling acceleration" "Scrolling acceleration" is a bit of a misnomer: it doesn't deal with acceleration at all. However, that's the name used in Logitech's spec, so I used it here. Signed-off-by: Harry Cutts <hcutts@chromium.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Verified-by: Harry Cutts <hcutts@chromium.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
fef33601 |
|
04-Dec-2018 |
Peter Hutterer <peter.hutterer@who-t.net> |
HID: logitech-hidpp: fix typo, hiddpp to hidpp Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Verified-by: Harry Cutts <hcutts@chromium.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
|
#
00acc9e2 |
|
21-Nov-2018 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
Revert "HID: logitech: Add function to enable HID++ 1.0 "scrolling acceleration"" This reverts commit 051dc9b0579602bd63e9df74d0879b5293e71581. It turns out the current API is not that compatible with some Microsoft mice, so better start again from scratch. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Harry Cutts <hcutts@chromium.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Jiri Kosina <jkosina@suse.cz>
|
#
5372fc37 |
|
21-Nov-2018 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
Revert "HID: logitech: Enable high-resolution scrolling on Logitech mice" This reverts commit d56ca9855bf924f3bc9807a3e42f38539df3f41f. It turns out the current API is not that compatible with some Microsoft mice, so better start again from scratch. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Harry Cutts <hcutts@chromium.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Jiri Kosina <jkosina@suse.cz>
|
#
a69616d5 |
|
21-Nov-2018 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
Revert "HID: logitech: Use LDJ_DEVICE macro for existing Logitech mice" This reverts commit 3fe1d6bbcd16f384d2c7dab2caf8e4b2df9ea7e6. It turns out the current API is not that compatible with some Microsoft mice, so better start again from scratch. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Harry Cutts <hcutts@chromium.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Jiri Kosina <jkosina@suse.cz>
|
#
d0341efe |
|
21-Nov-2018 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
Revert "HID: logitech: fix a used uninitialized GCC warning" This reverts commit 5fe2ccbef9d7aecf5c4402c753444f1a12096cfd. It turns out the current API is not that compatible with some Microsoft mice, so better start again from scratch. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Harry Cutts <hcutts@chromium.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Jiri Kosina <jkosina@suse.cz>
|
#
5fe2ccbe |
|
13-Sep-2018 |
zhong jiang <zhongjiang@huawei.com> |
HID: logitech: fix a used uninitialized GCC warning Fix the following compile warning: drivers/hid/hid-logitech-hidpp.c: In function 'hi_res_scroll_enable': drivers/hid/hid-logitech-hidpp.c:2714:54: warning: 'multiplier' may be used uninitialized in this function [-Wmaybe-uninitialized] hidpp->vertical_wheel_counter.resolution_multiplier = multiplier; Signed-off-by: zhong jiang <zhongjiang@huawei.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
3fe1d6bb |
|
30-Aug-2018 |
Harry Cutts <hcutts@chromium.org> |
HID: logitech: Use LDJ_DEVICE macro for existing Logitech mice Signed-off-by: Harry Cutts <hcutts@chromium.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
d56ca985 |
|
30-Aug-2018 |
Harry Cutts <hcutts@chromium.org> |
HID: logitech: Enable high-resolution scrolling on Logitech mice There are three features used by various Logitech mice for high-resolution scrolling: the scrolling acceleration bit in HID++ 1.0, and the x2120 and x2121 features in HID++ 2.0 and above. This patch supports all three, and uses the multiplier reported by the mouse for the HID++ 2.0+ features. The full list of product IDs of mice which support high-resolution scrolling was provided by Logitech, but the patch was tested using the following mice (using the Unifying receiver): * HID++ 1.0: Anywhere MX, Performance MX * x2120: M560 * x2121: MX Anywhere 2, MX Master 2S Signed-off-by: Harry Cutts <hcutts@chromium.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
051dc9b0 |
|
30-Aug-2018 |
Harry Cutts <hcutts@chromium.org> |
HID: logitech: Add function to enable HID++ 1.0 "scrolling acceleration" "Scrolling acceleration" is a bit of a misnomer: it doesn't deal with acceleration at all. However, that's the name used in Logitech's spec, so I used it here. Signed-off-by: Harry Cutts <hcutts@chromium.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
df47b246 |
|
14-Jul-2017 |
Colin Ian King <colin.king@canonical.com> |
HID: logitech-hidpp: fix mistake in printk, "feeback" -> "feedback" Trivial fix to spelling mistake in hid_info message and add line break to split an overly long line to clean up a checkpatch warning. Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-By: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
35a33cb5 |
|
03-Aug-2017 |
Arvind Yadav <arvind.yadav.cs@gmail.com> |
HID: logitech-hidpp: constify attribute_group structures. attribute_group are not supposed to change at runtime. All functions working with attribute_group provided by <linux/sysfs.h> work with const attribute_group. So mark the non-const structs as const. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
929b60a8 |
|
06-Jul-2017 |
Gustavo A. R. Silva <garsilva@embeddedor.com> |
HID: hid-logitech-hidpp: add NULL check on devm_kmemdup() return value Check return value from call to devm_kmemdup() in order to prevent a NULL pointer dereference. Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
a4bf6153 |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: add a sysfs file to tell we support power_supply This way, upower can add a simple udev rule to decide whether or not it should use the internal unifying support or just the generic kernel one. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
7f7ce2a2 |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: enable HID++ 1.0 battery reporting Also enable battery reporting for HID++ 1.0 devices through 2 registers: 0x07: battery status -> reports only 4 levels (critical, low, good, full) 0x0D: battery mileage -> reports true pourcentage Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
696ecef9 |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: add support for battery status for the K750 The Solar Keyboard uses a different feature to report the battery level. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
5b036ea1 |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: battery: provide CAPACITY_LEVEL CAPACITY LEVEL allows to forward rough information on the battery mileage. HID++ 2.0 devices will either report percentage or levels, so better forwarding this information to the user space. The M325 supports only 2 levels: 'Full' and 'Critical'. With mileage, it will report either 90% or 5%, which might confuse users. With this change the battery will either report "Full" or "Critical". Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
14f437a1 |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: rename battery level into capacity The power_supply term for the percentage is capacity. Capacity level can be given when non accurate mileage is provided by the device, so better stick to the terms used in power_supply. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
284f8d75 |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: battery: provide ONLINE property When ONLINE isn't set, upower should ignore the battery capacity, so there is no need to overload it with some random values. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
9b9c519f |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: notify battery on connect When a device reconnects, there is a high chance its power supply has been changed (for a battery replacement for instance). Just forward the battery state here. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
a9525b80 |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: return an error if the queried feature is not present Or the device just answers a valid feature '0'. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
a52ec107 |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: create the battery for all types of HID++ devices The creation of the power_supply should not be in a HID++ 2.0 specific function. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
32043d0f |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: forward device info in power_supply Better forwarding the device name, manufacturer and serial to upower. Note that serial is still empty, it will be filled in a later patch in this series. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
eb626c57 |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: handle battery events in hidpp_raw_hidpp_event() Battery events are reported through HID++, so we need to be sure the report ID is the HID++ one. Without this, we might receive keyboard events that looks just like battery events with wrong data and which will confuse user space. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
2936836f |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: rework hidpp_connect_event() Looks like all users don't care about a disconnect. Simplify the various variant_connect() and put the connect state check at the beginning. For delayed input devices, make sure we go through all other connect values (protocol, battery) before bailing out. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
187f2bba |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: retrieve the HID++ device name when available hidpp->name can't be null. Only HID++ 2.0 and above device supports the query. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
843c624e |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: rework probe path for unifying devices Unifying devices are different from others because they can probed while not connected. So we need to talk to the receiver to get some extra information like the device name and the serial. Instead of having conditionals while attempting to read the device name from HID++ 2.0, have a special init path for them. Store the retrieved serial in hdev->uniq. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
206d7c68 |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: create a capabilities bits field Do not pollute the quirks bits field which is public API with elements that are queried from the device. Move the 2 battery capabilities into the new field. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
b4f8ce07 |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: do not query the name through HID++ for 1.0 devices Unless they are connected through unifying, they don't support it, so remove one error in the logs. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
680de741 |
|
27-Mar-2017 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: make sure we only register one battery per device Simple check to add, huge improvement :) Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
3861e6ca |
|
27-Mar-2017 |
Bastien Nocera <hadess@hadess.net> |
HID: logitech-hidpp: Add scope to battery Without a scope defined, UPower assumes that the battery provides power to the computer it's connected to, like a laptop battery or a UPS. Tested-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
6bd4e65d |
|
29-Jun-2016 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: remove HIDPP_QUIRK_CONNECT_EVENTS Now that we can create battery power_supply sources, it's better to enable the connect_event callback unconditionally. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
5a2b190c |
|
29-Jun-2016 |
Peter Hutterer <peter.hutterer@who-t.net> |
HID: logitech-hidpp: add battery support for HID++ 2.0 devices If the 0x1000 Unified Battery Level Status feature exists, expose the battery level. The main drawback is that while a device is plugged in its battery level is 0. To avoid exposing that as 0% charge we make up a number based on the charging status. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
af2e628d |
|
28-Jan-2016 |
Jiri Kosina <jkosina@suse.cz> |
HID: logitech-hidpp: limit visibility of init/deinit functions hidpp_ff_init() and hidpp_ff_deinit() are not used outside of hid-logitech-hidpp.c, so let's make them static. Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
ff21a635 |
|
10-Jan-2016 |
Edwin Velds <e.velds@gmail.com> |
HID: logitech-hidpp: Force feedback support for the Logitech G920 This patch implements force feedback support for the Logitech G920 Driving Force Racing Wheel. It is a generic implementation of feature 0x8123 of the Logitech HID++ protocol and should be usable for any future devices that implement this feature. This patch should be applied after the basic G920 support patch by Simon Wood: http://www.spinics.net/lists/linux-input/msg42174.html The driving supports everything that is supported by the G920 firmware: FF_CONSTANT FF_PERIODIC FF_SINE FF_SQUARE FF_SAW_UP FF_SAW_DOWN FF_TRIANGLE FF_SPRING FF_DAMPER FF_AUTOCENTER FF_GAIN and for version 2 firmware also: FF_FRICTION FF_INERTIA FF_RAMP Both envelopes and replay values are supported as well, but some problems may occur when using firmware release 1. There is also a small residual clockwise damper in the wheel when using the first firmware release. All problems are fixed in the soon te be released firmware version 2. The default spring is disabled by permanently placing a spring force in the wheel. This spring is also used as the autocenter spring. Note: The wheel _DOES_NOT_ auto switch to Logitech/HID mode (it is stuck in XBox since the xpad changes where not included). Michal has an alternative approach documented here (and the changes should be submitted upstream to usb_modeswitch project): === Create a file named "046d:c261" in "/etc/usb_modeswitch.d" with the following content: DefaultVendor=046d DefaultProduct=c261 MessageEndpoint=01 ResponseEndpoint=01 TargetClass=0x03 MessageContent="0f00010142" Then run "usb_modeswitch -c /etc/modeswitch.d/046d:c291" as root and watch the magic happen:) === [jkosina@suse.cz: added information about mode switching from Simon] [jkosina@suse.cz: fixed a few stylistic issues pointed out by Simon] [jkosina@suse.cz: fix merge conflict due to to_hid_device() changes] Signed-off-by: Edwin Velds <e.velds@gmail.com> Tested-by: Elias Vanderstuyft <elias.vds@gmail.com> Tested-by: Simon Wood <simon@mungewell.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
d8ce9bf5 |
|
27-Dec-2015 |
Geliang Tang <geliangtang@163.com> |
HID: move to_hid_device() to hid.h to_hid_device() macro is defined in both hid-lg4ff.c and hid-logitech-hidpp.c. So I move it to include/linux/hid.h. Signed-off-by: Geliang Tang <geliangtang@163.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
0b1804e3 |
|
19-Nov-2015 |
Simon Wood <simon@mungewell.org> |
HID: hid-logitech-hidpp: G920 remove deadzones Ensure that the G920 is not given the default deadzones. Signed-off-by: Simon Wood <simon@mungewell.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
7f4b49fe |
|
19-Nov-2015 |
Simon Wood <simon@mungewell.org> |
HID: hid-logitech-hidpp: Add range sysfs for Logitech G920 The G920 can adjust the amount of 'turn' it permits, this patch adds a sysfs file 'range' to control this. Signed-off-by: Simon Wood <simon@mungewell.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
7bfd2927 |
|
19-Nov-2015 |
Simon Wood <simon@mungewell.org> |
HID: hid-logitech-hidpp: Add basic support for Logitech G920 This patch adds basic support for the Logitech G920 wheel when in HID mode. This wheel 'speaks' the HID++ protocol, and therefor is driven with hid-logitech-hidpp. At this stage the driver only shows that it can communicate with the wheel by outputting the name discovered over HID++. The normal HID functions work to give input functionality using joystick/event interface. Note: in 'hidpp_probe()' we have to start the hardware to get packets flowing, the same might apply in future for other devices which don't use the unifying protocol. Signed-off-by: Simon Wood <simon@mungewell.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
a5ce8f5b |
|
19-Nov-2015 |
Simon Wood <simon@mungewell.org> |
HID: hid-logitech-hidpp: Add support for very long packets Patch add support for the 'very long' HID++ packets, which are 64 bytes in length. Signed-off-by: Simon Wood <simon@mungewell.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
9154301a |
|
29-Sep-2015 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
HID: hid-input: allow input_configured callback return errors When configuring input device via input_configured callback we may encounter errors (for example input_mt_init_slots() may fail). Instead of continuing with half-initialized input device let's allow driver indicate failures. Signed-off-by: Jaikumar Ganesh <jaikumarg@android.com> Signed-off-by: Arve Hjønnevåg <arve@android.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com> Acked-by: Andrew Duggan <aduggan@synaptics.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
b2c68a2f |
|
29-Sep-2015 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
HID: hid-input: allow input_configured callback return errors When configuring input device via input_configured callback we may encounter errors (for example input_mt_init_slots() may fail). Instead of continuing with half-initialized input device let's allow driver indicate failures. Signed-off-by: Jaikumar Ganesh <jaikumarg@android.com> Signed-off-by: Arve Hjønnevåg <arve@android.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com> Acked-by: Andrew Duggan <aduggan@synaptics.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
90cdd986 |
|
03-Sep-2015 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: add support to disable tap-to-click on the K400 The Logitech K400 keyboard has an embedded touchpad which is seen as a mouse from the OS point of view. There is a hardware shortcut to disable tap-to-click but the setting is not remembered accross reset, annoying some users. We can toggle this feature from the host by using the feature 0x6010: Touchpad FW items Reported-by: BALATON Zoltan <balaton@eik.bme.hu> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
580a7e82 |
|
03-Sep-2015 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: split HIDPP_QUIRK_DELAYED_INIT in two HIDPP_QUIRK_DELAYED_INIT means two things currently: - we want to delay the initialization process - we do not want hid to create an input device based on the report descriptor. This should actually be 2 different quirks so we can have special connect events while still having HID creating the input for us. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
8a09b4fa |
|
30-May-2015 |
Goffredo Baroncelli <kreijack@inwind.it> |
HID: hidpp: Add driver for mouse logitech M560 The Logitech M560 is a wireless mouse designed for windows 8 which uses the unifying receiver. Compared to a standard one, some buttons (the middle one and the two ones placed on the side) are bound to a key combination instead of a generating classic "mouse" button events. The device shows up as a mouse and keyboard combination: when the middle button is pressed it sends a key (as keyboard) combination, the same happens for the two side button. The left/right/wheel work as expected from a mouse. To complicate things further, the middle button sends different keys combinations between odd and even presses. In the "even" press it also sends a left click. But the worst thing is that no event is generated when the middle button is released. It is possible to re-configure the mouse sending a command (see function m560_send_config_command()). After this command the mouse sends some useful data when the buttons are pressed and/or released. [jkosina@suse.cz: fix build breakage due to leftover from previous patch version] Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
5006c105 |
|
06-May-2015 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
Revert "HID: logitech-hidpp: support combo keyboard touchpad TK820" This reverts commit 3a61e97563d78a2ca10752902449570d8433ce76. The Logitech TK820 seems to be affected by a firmware bug which delays the sending of the keys (pressed, or released, which triggers a key-repeat) while holding fingers on the touch sensor. This behavior can be observed while using the mouse emulation mode if the user moves the finger while typing (highly improbable though). Holding the finger still while in the mouse emulation mode does not trigger the key repeat problem. So better keep things in their previous state to not have to explain users that the new key-repeat bug they see is a "feature". Furthermore, I noticed that I disabled the media keys whith this patch. Sorry, my bad. I think it is best to revert the patch, in all the current versions it has been shipped. Cc: <stable@vger.kernel.org> # v3.19 and above Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
b832da56 |
|
05-Apr-2015 |
Julia Lawall <Julia.Lawall@lip6.fr> |
HID: logitech-hidpp: fix error return code Return a negative error code on failure. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier ret; expression e1,e2; @@ ( if (\(ret < 0\|ret != 0\)) { ... return ret; } | ret = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
9188dbae |
|
25-Mar-2015 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: add a module parameter to keep firmware gestures The Logitech T650 used to report 3 fingers swipes to the up as a press on the Super key. When we switched the touchpad to the raw mode, we also disable such firmware gesture and some users may rely on it. Unfortunately, 3 finger swipes are still not supported in most of the Linux environments, which means that we disabled a feature of the touchpad. Allow users to revert the raw reporting mode and keep going with the firmware gestures by providing a new module parameter. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
005b3f57 |
|
08-Jan-2015 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: store the name of the device in struct hidpp If a disconnect occurs while getting the actual name of the device (which can take several HID transactions), the name of the device will be the hid name, provided by the Unifying Receiver. This means that in some cases, the user space will see a different name that what it usually sees when there is no disconnect. We should store the name of the device in the struct hidpp. That way, if a disconnect occurs while we are accessing the name, hidpp_connect_event() can fail, and the input node is not created. The input node will be created only if we have a connection which lasts long enough to retrieve all the requested information: name, protocol, and specific configuration. Reviewed-by: Peter Wu <peter@lekensteyn.nl> Tested-by: Peter Wu <peter@lekensteyn.nl> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
a0e625f8 |
|
11-Dec-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: prefix the name with "Logitech" Current names are reported as "K750", "M705", and it can be misleading for the users when they look at their input device list. Prefixing the names with "Logitech " makes things better. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
8abd8205 |
|
15-Dec-2014 |
Peter Wu <peter@lekensteyn.nl> |
HID: logitech-hidpp: avoid unintended fall-through Add a return to avoid a fall-through. Introduced in commit 57ac86cf52e903d9e3e0f12b34c814cce6b65550 ("HID: logitech-hidpp: add support of the first Logitech Wireless Touchpad"). Signed-off-by: Peter Wu <peter@lekensteyn.nl> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
f677bb15 |
|
15-Dec-2014 |
Peter Wu <peter@lekensteyn.nl> |
HID: logitech-hidpp: detect HID++ 2.0 errors too Devices speaking HID++ 2.0 report a different error code (0xff). Detect these errors too to avoid 5 second delays when the device reports an error. Caught by... well, a bug in the QEMU emulation of this receiver. Renamed fap to rap for HID++ 1.0 errors because it is more logical, it has no functional difference. Signed-off-by: Peter Wu <peter@lekensteyn.nl> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
b1ac9487 |
|
11-Dec-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: prefix the name with "Logitech" Current names are reported as "K750", "M705", and it can be misleading for the users when they look at their input device list. Prefixing the names with "Logitech " makes things better. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
bf159447 |
|
16-Dec-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: bail out if wtp_connect fails If wtp_connect() fails, that means most of the time that the device has been disconnected. Subsequent attempts to contact the device will fail too, so it's simpler to bail out earlier. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
e529fea9 |
|
16-Dec-2014 |
Peter Wu <peter@lekensteyn.nl> |
HID: logitech-hidpp: separate HID++ from WTP processing Previously wtp_raw_event would be called through hidpp_raw_hidpp_event (for the touchpad report) and hidpp_raw_event (for the mouse report). This patch removes one calling surface, making a clearer distinction between "generic HID++ processing" (matching internal reports) and device-specific event processing. Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Peter Wu <peter@lekensteyn.nl> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
0b3f6569 |
|
16-Dec-2014 |
Peter Wu <peter@lekensteyn.nl> |
HID: logitech-hidpp: check WTP report length Malicious USB devices can send bogus reports smaller than the expected buffer size. Ensure that the length for WTP reports 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>
|
#
f486d9db |
|
11-Dec-2014 |
Peter Wu <peter@lekensteyn.nl> |
HID: logitech-hidpp: disable io in probe error path Balance a hid_device_io_start() call with hid_device_io_stop() in the error path. This avoids processing of HID reports when the probe fails which possibly leads to invalid memory access in hid_device_probe() as report_enum->report_id_hash might already be freed via hid_close_report(). hid_set_drvdata() is called before wtp_allocate, be consistent and clear drvdata too on the error path of wtp_allocate. Signed-off-by: Peter Wu <peter@lekensteyn.nl> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
3a034a7a |
|
11-Dec-2014 |
Peter Wu <peter@lekensteyn.nl> |
HID: logitech-hidpp: add boundary check for name retrieval The HID response has a limited size. Do not trust the value returned by hardware, check that it really fits in the message. Signed-off-by: Peter Wu <peter@lekensteyn.nl> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
1430ee73 |
|
11-Dec-2014 |
Peter Wu <peter@lekensteyn.nl> |
HID: logitech-hidpp: check name retrieval return code hidpp_devicenametype_get_device_name() may return a negative value on protocol errors (for example, when the device is powered off). Explicitly check this condition to avoid a long-running loop. (0 cannot be returned as __name_length - index > 0, but check for it anyway as it would otherwise result in an infinite loop.) Signed-off-by: Peter Wu <peter@lekensteyn.nl> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
02cc097e |
|
11-Dec-2014 |
Peter Wu <peter@lekensteyn.nl> |
HID: logitech-hidpp: do not return the name length We do not make any use of the actual name length get through hidpp_get_device_name(). Original patch by Benjamin Tissoires, this patch also replaces a (now) unnecessary goto by return NULL. Signed-off-by: Peter Wu <peter@lekensteyn.nl> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
552f12eb |
|
03-Nov-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: 2 fixes in hidpp_root_get_protocol_version() - remove the constant '1' - when the device is not connected, the protocol error HIDPP_ERROR_RESOURCE_ERROR is raised. We should not warn the user about it because it is somewhat expected as an answer when we check if the device is connected. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
8c9952b2 |
|
03-Nov-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: fix negated returns Reported by Dan Carpenter: drivers/hid/hid-logitech-hidpp.c:359 hidpp_root_get_protocol_version() warn: should this return really be negated? drivers/hid/hid-logitech-hidpp.c:398 hidpp_devicenametype_get_count() warn: should this return really be negated? drivers/hid/hid-logitech-hidpp.c:417 hidpp_devicenametype_get_device_name() warn: should this return really be negated? drivers/hid/hid-logitech-hidpp.c:524 hidpp_touchpad_get_raw_info() warn: should this return really be negated? The problem lies in hidpp_send_message_sync() which can return 2 types of errors depending of their sign. Adding a comment there to clarify what is happening. To solve that, print an error in case of a protocol problem, and raise -EPROTO instead. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
3e7830ce |
|
30-Oct-2014 |
Dan Carpenter <dan.carpenter@oracle.com> |
HID: logitech-hidpp: leaks and NULL dereferences Shift the allocation down a few lines to avoid a memory leak and also add a check for allocation failure. Fixes: 2f31c5252910 ('HID: Introduce hidpp, a module to handle Logitech hid++ devices') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
3a61e975 |
|
30-Sep-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: support combo keyboard touchpad TK820 The TK820 presents both a keyboard and a touchpad on the same physical (and logical device). Use the generic hid-input processing for the keyboard part. The keyboard input device is created when the receiver is plugged in, so no events are missed on connect. When the device actaully connects, we can set it to use the raw multitouch reporting to have a consistent user experience accross all Logitech touchpads. 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>
|
#
57ac86cf |
|
30-Sep-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: add support of the first Logitech Wireless Touchpad This touchpad differs from the T650 in several ways: - the resolution is not correctly returned by the device - it presents physical buttons, so the button flag in the raw touch report is not filled. 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>
|
#
586bdc4e |
|
30-Sep-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: Add Wireless Touchpad T650 support All the bits are now in place to add the support of the Touchpad T650. The creation/population of the input device is delayed until the device is ready. The T650 uses the special HID++ reporting protocol, so activate this on connect. 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>
|
#
c39e3d5f |
|
30-Sep-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: logitech-hidpp: late bind the input device on wireless connection Now that the receiver forwards the connect/disconnect events, we can know when the device is available to communicate with us. When it is ready, we can for instance retrieve its full name, which guarantee that we always have the same name for the DJ device (the DJ name is somewhat shorter than the HID++ name). This mechanism is mandatory for the touchpads line, which has the min/max information stored in the device. This information can only be retrieved when the device is connected. So we can not populate the input device until we are sure that the device is connected. This patch creates a new input device for such devices. However, this input is not bound to hid directly, so the various drivers which wants to use it are required to process completely the incoming reports in .raw_event(). Note that the patch in itself just adds the bits for the next ones, and this feature is disabled by default. 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>
|
#
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>
|
#
2f31c525 |
|
30-Sep-2014 |
Benjamin Tissoires <benjamin.tissoires@redhat.com> |
HID: Introduce hidpp, a module to handle Logitech hid++ devices Logitech devices use a vendor protocol to communicate various information with the device. This protocol is called HID++, and an exerpt can be found here: https://drive.google.com/folderview?id=0BxbRzx7vEV7eWmgwazJ3NUFfQ28&usp=shar The main difficulty which is related to this protocol is that it is a synchronous protocol using the input reports. So when we want to get some information from the device, we need to wait for a matching input report. This driver introduce this capabilities to be able to support the multitouch mode of the Logitech Wireless Touchpad T651 (the bluetooth one). The multitouch data is available directly from the mouse input reports, and we just need to query the device on connect about its caracteristics. HID++ and the touchpad features has a specific reporting mode which uses pure HID++ reports, but Logitech told us not to use it for this specific device. During QA, they detected that some bluetooth input reports where lost, and so the only supported mode is the pointer mode. 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>
|