summaryrefslogtreecommitdiff
path: root/drivers/hid/hid-logitech-hidpp.c
AgeCommit message (Collapse)Author
2019-11-29Merge branch 'for-5.5/logitech' into for-linusJiri Kosina
- Support for Logitech G15 (Hans de Goede) - silencing of non-informative error flow in dmesg from logitechi-hiddpp (Hans de Goede)
2019-11-15HID: logitech-hidpp: Silence intermittent get_battery_capacity errorsHans de Goede
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>
2019-10-18HID: logitech-hidpp: do all FF cleanup in hidpp_ff_destroy()Andrey Smirnov
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>
2019-10-18HID: logitech-hidpp: rework device validationAndrey Smirnov
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>
2019-10-18HID: logitech-hidpp: split g920_get_config()Andrey Smirnov
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>
2019-10-03HID: Fix assumption that devices have inputsAlan Stern
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>
2019-08-13HID: logitech-hidpp: remove support for the G700 over USBBenjamin Tissoires
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>
2019-08-13Revert "HID: logitech-hidpp: add USB PID for a few more supported mice"Benjamin Tissoires
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>
2019-07-17HID: logitech-hidpp: add USB PID for a few more supported miceFilipe Laíns
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>
2019-07-10Merge branches 'for-5.2/fixes', 'for-5.3/doc', 'for-5.3/ish', ↵Jiri Kosina
'for-5.3/logitech' and 'for-5.3/wacom' into for-linus
2019-06-13Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Jiri Kosina: - regression fixes (reverts) for module loading changes that turned out to be incompatible with some userspace, from Benjamin Tissoires - regression fix for special Logitech unifiying receiver 0xc52f, from Hans de Goede - a few device ID additions to logitech driver, from Hans de Goede - fix for Bluetooth support on 2nd-gen Wacom Intuos Pro, from Jason Gerecke * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: logitech-dj: Fix 064d:c52f receiver support Revert "HID: core: Call request_module before doing device_add" Revert "HID: core: Do not call request_module() in async context" Revert "HID: Increase maximum report size allowed by hid_field_extract()" HID: a4tech: fix horizontal scrolling HID: hyperv: Add a module description line HID: logitech-hidpp: Add support for the S510 remote control HID: multitouch: handle faulty Elo touch device HID: wacom: Sync INTUOSP2_BT touch state after each frame if necessary HID: wacom: Correct button numbering 2nd-gen Intuos Pro over Bluetooth HID: wacom: Send BTN_TOUCH in response to INTUOSP2_BT eraser contact HID: wacom: Don't report anything prior to the tool entering range HID: wacom: Don't set tool type until we're in range HID: rmi: Use SET_REPORT request on control endpoint for Acer Switch 3 and 5 HID: logitech-hidpp: add support for the MX5500 keyboard HID: logitech-dj: add support for the Logitech MX5500's Bluetooth Mini-Receiver HID: i2c-hid: add iBall Aer3 to descriptor override
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 441Thomas Gleixner
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>
2019-05-22HID: logitech-hidpp: Add support for the S510 remote controlHans de Goede
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>
2019-05-22HID: logitech-hidpp: HID: make const array consumer_rdesc_start staticColin Ian King
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>
2019-05-09HID: logitech-hidpp: add support for the MX5500 keyboardHans de Goede
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>
2019-04-23HID: logitech-hidpp: add support for HID++ 1.0 consumer keys reportsHans de Goede
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>
2019-04-23HID: logitech-hidpp: add support for HID++ 1.0 extra mouse buttons reportsHans de Goede
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>
2019-04-23HID: logitech-hidpp: add support for HID++ 1.0 wheel reportsHans de Goede
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>
2019-04-23HID: logitech-hidpp: make hidpp10_set_register_bit a bit more genericHans de Goede
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>
2019-04-23HID: logitech-hidpp: add input_device ptr to struct hidpp_deviceHans de Goede
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>
2019-04-23HID: logitech-hidpp: do not hardcode very long report lengthHans de Goede
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>
2019-04-23HID: logitech-hidpp: handle devices attached to 27MHz wireless receiversHans de Goede
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>
2019-04-23HID: logitech-hidpp: use RAP instead of FAP to get the protocol versionHans de Goede
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>
2019-04-23HID: logitech-hidpp: remove unused origin_is_hid_core function parameterHans de Goede
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>
2019-04-23HID: logitech-hidpp: remove double assignment from __hidpp_send_reportHans de Goede
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>
2019-04-23HID: logitech-hidpp: do not make failure to get the name fatalHans de Goede
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>
2019-04-23HID: logitech-hidpp: ignore very-short or empty namesHans de Goede
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>
2019-04-23HID: logitech-hidpp: make .probe usbhid capableBenjamin Tissoires
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>
2019-04-23HID: logitech-hidpp: allow non HID++ devices to be handled by this moduleBenjamin Tissoires
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>
2019-04-23HID: logitech: Stop setting drvdata to NULL on probe failure and removeBenjamin Tissoires
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>
2019-04-23Merge branch 'for-5.1/upstream-fixes' into for-5.2/logitechBenjamin Tissoires
2019-04-01HID: logitech-hidpp: change low battery level threshold from 31 to 30 percentHans de Goede
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>
2019-04-01HID: logitech-hidpp: remove hidpp_is_connected()Hans de Goede
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>
2019-04-01HID: logitech-hidpp: simplify printing of HID++ versionHans de Goede
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>
2019-03-20HID: logitech: Handle 0 scroll events for the m560Peter Hutterer
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>
2019-03-19HID: logitech: check the return value of create_singlethread_workqueueKangjie Lu
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>
2018-12-07HID: logitech: Use LDJ_DEVICE macro for existing Logitech miceHarry Cutts
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>
2018-12-07HID: logitech: Enable high-resolution scrolling on Logitech miceHarry Cutts
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>
2018-12-07HID: logitech: Add function to enable HID++ 1.0 "scrolling acceleration"Harry Cutts
"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>
2018-12-07HID: logitech-hidpp: fix typo, hiddpp to hidppPeter Hutterer
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>
2018-11-22Revert "HID: logitech: Add function to enable HID++ 1.0 "scrolling ↵Benjamin Tissoires
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>
2018-11-22Revert "HID: logitech: Enable high-resolution scrolling on Logitech mice"Benjamin Tissoires
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>
2018-11-22Revert "HID: logitech: Use LDJ_DEVICE macro for existing Logitech mice"Benjamin Tissoires
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>
2018-11-22Revert "HID: logitech: fix a used uninitialized GCC warning"Benjamin Tissoires
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>
2018-09-24HID: logitech: fix a used uninitialized GCC warningzhong jiang
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>
2018-09-05HID: logitech: Use LDJ_DEVICE macro for existing Logitech miceHarry Cutts
Signed-off-by: Harry Cutts <hcutts@chromium.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2018-09-05HID: logitech: Enable high-resolution scrolling on Logitech miceHarry Cutts
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>
2018-09-05HID: logitech: Add function to enable HID++ 1.0 "scrolling acceleration"Harry Cutts
"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>
2017-10-12HID: logitech-hidpp: fix mistake in printk, "feeback" -> "feedback"Colin Ian King
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>
2017-08-03HID: logitech-hidpp: constify attribute_group structures.Arvind Yadav
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>
generated by cgit (git 2.34.1) at 2024-05-29 12:39:45 +0000