summaryrefslogtreecommitdiffstats
path: root/include/linux/hid.h
Commit message (Collapse)AuthorAgeFilesLines
* HID: core: Add printk_once variants to hid_warn() etcJoshua Clayton2019-09-181-0/+11
| | | | | | | hid_warn_once() is needed. Add the others as part of the block. Signed-off-by: Joshua Clayton <stillcompiling@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
* HID: core: reformat and reduce hid_printk macrosJoshua Clayton2019-09-181-20/+12
| | | | | | | | | Reformat hid_printk macros to use standard __VA_ARGS__ syntax. Per Joe Perches hid_printk(), hid_emerg(), hid_crit(), and hid_alert() are unlikely ever to be used. Remove them. Signed-off-by: Joshua Clayton <stillcompiling@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
* treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 156Thomas Gleixner2019-05-301-13/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111 1307 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1334 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
*---. Merge branches 'for-5.1/upstream-fixes', 'for-5.2/core', 'for-5.2/ish', ↵Jiri Kosina2019-05-061-0/+2
|\ \ \ | | | | | | | | | | | | 'for-5.2/logitech', 'for-5.2/macally', 'for-5.2/picolcd', 'for-5.2/sensor' and 'for-5.2/u2fzero' into for-linus
| | | * HID: logitech-dj: add support for 27 MHz receiversHans de Goede2019-04-231-0/+1
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most Logitech wireless keyboard and mice using the 27 MHz are hidpp10 devices, add support to logitech-dj for their receivers. Doing so leads to 2 improvements: 1) All these devices share the same USB product-id for their receiver, making it impossible to properly map some special keys / buttons which differ from device to device. Adding support to logitech-dj to see these as hidpp10 devices allows us to get the actual device-id from the keyboard / mouse. 2) It enables battery-monitoring of these devices This patch uses a new HID group for 27Mhz devices, since the logitech-hidpp code needs to be able to differentiate them from other devices instantiated by the logitech-dj code. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
| * | HID: core: move Usage Page concatenation to Main itemNicolas Saenz Julienne2019-04-021-0/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As seen on some USB wireless keyboards manufactured by Primax, the HID parser was using some assumptions that are not always true. In this case it's s the fact that, inside the scope of a main item, an Usage Page will always precede an Usage. The spec is not pretty clear as 6.2.2.7 states "Any usage that follows is interpreted as a Usage ID and concatenated with the Usage Page". While 6.2.2.8 states "When the parser encounters a main item it concatenates the last declared Usage Page with a Usage to form a complete usage value." Being somewhat contradictory it was decided to match Window's implementation, which follows 6.2.2.8. In summary, the patch moves the Usage Page concatenation from the local item parsing function to the main item parsing function. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Terry Junge <terry.junge@poly.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
* | HID: input: make sure the wheel high resolution multiplier is setBenjamin Tissoires2019-04-241-1/+1
|/ | | | | | | | | | | | | | | Some old mice have a tendency to not accept the high resolution multiplier. They reply with a -EPIPE which was previously ignored. Force the call to resolution multiplier to be synchronous and actually check for the answer. If this fails, consider the mouse like a normal one. Fixes: 2dc702c991e377 ("HID: input: use the Resolution Multiplier for high-resolution scrolling") Link: https://bugzilla.redhat.com/show_bug.cgi?id=1700071 Reported-and-tested-by: James Feeney <james@nurealm.net> Cc: stable@vger.kernel.org # v5.0+ Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
* HID: core: simplify active collection trackingPhilipp Zabel2019-01-161-1/+0
| | | | | | | | | | Manually tracking an active collection to set collection parents is not necessary, we just have to look one step back into the collection stack to find the correct parent. Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
* HID: core: replace the collection tree pointers with indicesPeter Hutterer2019-01-101-2/+2
| | | | | | | | | | | | | | | Previously, the pointer to the parent collection was stored. If a device exceeds 16 collections (HID_DEFAULT_NUM_COLLECTIONS), the array to store the collections is reallocated, the pointer to the parent collection becomes invalid. Replace the pointers with an index-based lookup into the collections array. Fixes: c53431eb696f3c ("HID: core: store the collections as a basic tree") Reported-by: Pandruvada, Srinivas <srinivas.pandruvada@intel.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Tested-by: Kyle Pelton <kyle.d.pelton@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
*---. Merge branches 'for-4.20/upstream-fixes', 'for-4.21/core', ↵Jiri Kosina2019-01-031-1/+16
|\ \ \ | | | | | | | | | | | | 'for-4.21/hid-asus', 'for-4.21/hid-core', 'for-4.21/hid-cougar', 'for-4.21/hidraw', 'for-4.21/highres-wheel' and 'for-4.21/ish' into for-linus
| | | * HID: input: use the Resolution Multiplier for high-resolution scrollingPeter Hutterer2018-12-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Windows uses a magic number of 120 for a wheel click. High-resolution scroll wheels are supposed to use a fraction of 120 to signal smaller scroll steps. This is implemented by the Resolution Multiplier in the device itself. If the multiplier is present in the report descriptor, set it to the logical max and then use the resolution multiplier to calculate the high-resolution events. This is the recommendation by Microsoft, see http://msdn.microsoft.com/en-us/windows/hardware/gg487477.aspx Note that all mice encountered so far have a logical min/max of 0/1, so it's a binary "yes or no" to high-res scrolling anyway. To make userspace simpler, always enable the REL_WHEEL_HI_RES bit. Where the device doesn't support high-resolution scrolling, the value for the high-res data will simply be a multiple of 120 every time. For userspace, if REL_WHEEL_HI_RES is available that is the one to be used. Potential side-effect: a device with a Resolution Multiplier applying to other Input items will have those items set to the logical max as well. This cannot easily be worked around but it is doubtful such devices exist. 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>
| | | * HID: core: process the Resolution MultiplierPeter Hutterer2018-12-071-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Resolution Multiplier is a feature report that modifies the value of Usages within the same Logical Collection. If the multiplier is set to anything but 1, the hardware reports (value * multiplier) for the same amount of physical movement, i.e. the value we receive in the kernel is pre-multiplied. The hardware may either send a single (value * multiplier), or by sending multiplier as many reports with the same value, or a combination of these two options. For example, when the Microsoft Sculpt Ergonomic mouse Resolution Multiplier is set to 12, the Wheel sends out 12 for every detent but AC Pan sends out a value of 3 at 4 times the frequency. The effective multiplier is based on the physical min/max of the multiplier field, a logical min/max of [0,1] with a physical min/max of [1,8] means the multiplier is either 1 or 8. The Resolution Multiplier was introduced for high-resolution scrolling in Windows Vista and is commonly used on Microsoft mice. The recommendation for the Resolution Multiplier is to default to 1 for backwards compatibility. This patch adds an arbitrary upper limit at 255. The only known use case for the Resolution Multiplier is for scroll wheels where the multiplier has to be a fraction of 120 to work with Windows. 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>
| | | * HID: core: store the collections as a basic treePeter Hutterer2018-12-071-0/+2
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | For each collection parsed, store a pointer to the parent collection (if any). This makes it a lot easier to look up which collection(s) any given item is part of 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>
| * | HID: input: support Microsoft wireless radio control hotkeyChris Chiu2018-12-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ASUS laptops start to support the airplane mode radio management to replace the original mechanism of airplane mode toggle hotkey. On the ASUS P5440FF, it presents as a HID device connecting via I2C, named i2c-AMPD0001. When pressing it, the Embedded Controller send hid report via I2C and switch the airplane mode indicator LED based on the status. However, it's not working because it fails to be identified as a hidinput device. It fails in hidinput_connect() due to the macro IS_INPUT_APPLICATION doesn't have HID_GD_WIRELESS_RADIO_CTLS as a legit application code. It's easy to add the HID I2C vendor and product id to the quirk list and apply HID_QUIRK_HIDINPUT_FORCE to make it work. But it makes more sense to support it as a generic input application. Signed-off-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
| * | HID: use macros in IS_INPUT_APPLICATIONChris Chiu2018-12-051-1/+5
|/ / | | | | | | | | | | | | | | Add missing definition for HID_DG_WHITEBOARD then replace the hid usage hex with macros for better readibility. Signed-off-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
* | Revert "HID: input: Create a utility class for counting scroll events"Benjamin Tissoires2018-11-221-28/+0
|/ | | | | | | | | | | | This reverts commit 1ff2e1a44e02d4bdbb9be67c7d9acc240a67141f. 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>
* HID: fix up .raw_event() documentationLinus Walleij2018-11-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | The documentation for the .raw_event() callback says that if the driver return 1, there will be no further processing of the event, but this is not true, the actual code in hid-core.c looks like this: if (hdrv && hdrv->raw_event && hid_match_report(hid, report)) { ret = hdrv->raw_event(hid, report, data, size); if (ret < 0) goto unlock; } ret = hid_report_raw_event(hid, type, data, size, interrupt); The only return value that has any effect on the processing is a negative error. Correct this as it seems to confuse people: I found bogus code in the Razer out-of-tree driver attempting to return 1 here. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* Merge branch 'for-4.20/logitech-highres' into for-linusJiri Kosina2018-10-231-0/+28
|\ | | | | | | High-resolution support for hid-logitech
| * HID: input: Create a utility class for counting scroll eventsHarry Cutts2018-09-051-0/+28
| | | | | | | | | | | | | | | | | | | | | | To avoid code duplication, this class counts high-resolution scroll movements and emits the legacy low-resolution events when appropriate. Drivers should be able to create one instance for each scroll wheel that they need to handle. Signed-off-by: Harry Cutts <hcutts@chromium.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | HID: core: fix grouping by applicationBenjamin Tissoires2018-09-041-0/+1
|/ | | | | | | | | | | | | | | | | | | | | | commit f07b3c1da92d ("HID: generic: create one input report per application type") was effectively the same as MULTI_INPUT: hidinput->report was never set, so hidinput_match_application() always returned null. Fix that by testing against the real application. Note that this breaks some old eGalax touchscreens that expect MULTI_INPUT instead of HID_QUIRK_INPUT_PER_APP. Enable this quirk for backward compatibility on all non-Win8 touchscreens. link: https://bugzilla.kernel.org/show_bug.cgi?id=200847 link: https://bugzilla.kernel.org/show_bug.cgi?id=200849 link: https://bugs.archlinux.org/task/59699 link: https://github.com/NixOS/nixpkgs/issues/45165 Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* Merge branch 'for-4.19/multitouch-multiaxis' into for-linusJiri Kosina2018-08-201-4/+11
|\ | | | | | | | | | | | | | | Multitouch updates: - Dial support - Palm rejection for touchscreens - a few small assorted fixes
| * HID: core: do not upper bound the collection stackBenjamin Tissoires2018-07-171-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Looks like 4 was sufficient until now. However, the Surface Dial needs a stack of 5 and simply fails at probing. Dynamically add HID_COLLECTION_STACK_SIZE to the size of the stack if we hit the upper bound. Checkpatch complains about bare unsigned, so converting those to 'unsigned int' in struct hid_parser Acked-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>
| * HID: input: enable Totem on the Dell Canvas 27Benjamin Tissoires2018-07-171-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Dell Canvas 27 has a tool that can be put on the surface and acts as a dial. The firmware processes the detection of the tool and forward regular HID reports with X, Y, Azimuth, rotation, width/height. The firmware also exports Contact ID, Countact Count which may hint that several totems can be used at the same time (the FW only supports one). We can tell that MT_TOOL_DIAL will be reported by setting the min/max of ABS_MT_TOOL_TYPE to MT_TOOL_DIAL. This tool is aimed at being used by the system and not the applications, so the user space processing should not go through the regular touch inputs. We set INPUT_PROP_DIRECT which applies ID_INPUT_TOUCHSCREEN to this new type of devices, but we will counter this for the time being with the special udev hwdb entry mentioned above. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1511846 Acked-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>
* | HID: cougar: make compare_device_paths reusableDaniel M. Lambea2018-07-231-0/+2
|/ | | | | | | | | | The function compare_device_paths from wacom_sys.c is generic and useful for other drivers. Move the function to hid-core and rename it as hid_compare_device_paths. Signed-off-by: Daniel M. Lambea <dmlambea@gmail.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: core: allow concurrent registration of driversBenjamin Tissoires2018-06-251-1/+2
| | | | | | | | | | | | | | | | | | | Detected on the Dell XPS 9365. The laptop has 2 devices that benefit from the hid-generic auto-unbinding. When those 2 devices are presented to the userspace, udev loads both wacom and hid-multitouch. When this happens, the code in __hid_bus_reprobe_drivers() is called concurrently and the second device gets reprobed twice. An other bug in the power_supply subsystem prevent to remove the wacom driver if it just finished its initialization, which basically kills the wacom node. [jkosina@suse.cz: reformat changelog a bit] Fixes c17a7476e4c4 ("HID: core: rewrite the hid-generic automatic unbind") Cc: stable@vger.kernel.org # v4.17 Tested-by: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* Merge branch 'for-4.18/multitouch' into for-linusJiri Kosina2018-06-081-3/+15
|\ | | | | | | | | - improvement of duplicate usage handling in hid-input from Benjamin Tissoires - Win 8.1 precisioun touchpad spec implementation from Benjamin Tissoires
| * HID: multitouch: implement precision touchpad latency and switchesBenjamin Tissoires2018-04-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | The Win 8.1 precision touchpad spec introduce new modes for touchpads that can come in handy[1]. Implement the settings of these modes, so we are not taken off-guard if a firmware decides to enforce them. [1] https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-precision-touchpad-required-hid-top-level-collections Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| * HID: input: append a suffix matching the applicationBenjamin Tissoires2018-04-261-0/+1
| | | | | | | | | | | | | | | | Given that we create one input node per application, we should name the input node accordingly to not lose userspace. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| * HID: generic: create one input report per application typeBenjamin Tissoires2018-04-261-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is not a good idea to try to fit all types of applications in the same input report. There are a lot of devices that are needing the quirk HID_MULTI_INPUT but this quirk doesn't match the actual HID description as it is based on the report ID. Given that most devices with MULTI_INPUT I can think of split nicely the devices inputs into application, it is a good thing to split the devices by default based on this assumption. Also make hid-multitouch following this rule, to not have to deal with too many input created. While we are at it, fix some checkpatch complaints about converting 'unsigned' to 'unsigned int'. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| * HID: store the full list of reports in the hidinputBenjamin Tissoires2018-04-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We were only storing the report in case of QUIRK_MULTI_INPUT. It is interesting for the upcoming HID_QUIRK_INPUT_PER_APP to also store the full list of reports that are attached to it. We need the full list because a device (Advanced Silicon has some) might want to use a different report ID for the Input reports and the Output reports. Storing the full list allows the drivers to have all the data. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| * HID: input: do not increment usages when a duplicate is foundBenjamin Tissoires2018-04-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is something that bothered us from a long time. When hid-input doesn't know how to map a usage, it uses *_MISC. But there is something else which increments the usage if the evdev code is already used. This leads to few issues: - some devices may have their ABS_X mapped to ABS_Y if they export a bad set of usages (see the DragonRise joysticks IIRC -> fixed in a specific HID driver) - *_MISC + N might (will) conflict with other defined axes (my Logitech H800 exports some multitouch axes because of that) - this prevents to freely add some new evdev usages, because "hey, my headset will now report ABS_COFFEE, and it's not coffee capable". So let's try to kill this nonsense, and hope we won't break too many devices. I my headset case, the ABS_MISC axes are created because of some proprietary usages, so we might not break that many devices. For backward compatibility, a quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE is created and can be applied to any device that needs this behavior. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | HID: add driver for Valve Steam ControllerRodrigo Rivas Costa2018-05-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two ways to connect the Steam Controller: directly to the USB or with the USB wireless adapter. Both methods are similar, but the wireless adapter can connect up to 4 devices at the same time. The wired device will appear as 3 interfaces: a virtual mouse, a virtual keyboard and a custom HID device. The wireless device will appear as 5 interfaces: a virtual keyboard and 4 custom HID devices, that will remain silent until a device is actually connected. The custom HID device has a report descriptor with all vendor specific usages, so the hid-generic is not very useful. In a PC/SteamBox Valve Steam Client provices a software translation by using hidraw and a creates a uinput virtual gamepad and XTest keyboard/mouse. This driver intercepts the hidraw usage, so it can get out of the way when the Steam Client is in use. Signed-off-by: Rodrigo Rivas Costa <rodrigorivascosta@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | HID: input: fix battery level reporting on BT miceDmitry Torokhov2018-04-091-1/+8
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | The commit 581c4484769e ("HID: input: map digitizer battery usage") assumed that devices having input (qas opposed to feature) report for battery strength would report the data on their own, without the need to be polled by the kernel; unfortunately it is not so. Many wireless mice do not send unsolicited reports with battery strength data and have to be polled explicitly. As a complication, stylus devices on digitizers are not normally connected to the base and thus can not be polled - the base can only determine battery strength in the stylus when it is in proximity. To solve this issue, we add a special flag that tells the kernel to avoid polling the device (and expect unsolicited reports) and set it when report field with physical usage of digitizer stylus (HID_DG_STYLUS). Unless this flag is set, and we have not seen the unsolicited reports, the kernel will attempt to poll the device when userspace attempts to read "capacity" and "state" attributes of power_supply object corresponding to the devices battery. Fixes: 581c4484769e ("HID: input: map digitizer battery usage") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198095 Cc: stable@vger.kernel.org Reported-and-tested-by: Martin van Es <martin@mrvanes.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* Merge branch 'for-4.17/upstream' into for-linusJiri Kosina2018-04-051-4/+0
|\ | | | | | | Pull a few small generic code cleanups.
| * HID: core: rewrite the hid-generic automatic unbindBenjamin Tissoires2018-03-061-4/+0
| | | | | | | | | | | | | | | | | | | | We actually can have the unbind/rebind logic in hid-core.c, leaving only the match function in hid-generic. This makes hid-generic simpler and the whole logic simpler too. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | Merge branch 'for-4.17/multitouch' into for-linusJiri Kosina2018-04-051-32/+33
|\ \ | | | | | | | | | Pull Razer Blade Stealth support improvement and a few generic cleanups
| * | HID: core: remove the need for HID_QUIRK_NO_EMPTY_INPUTBenjamin Tissoires2018-03-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no real point of registering an empty input node. This should be default, but given some drivers need the blank input node to set it up during input_configured, we need to postpone the check for hidinput_has_been_populated(). Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| * | HID: use BIT() macro for quirks tooBenjamin Tissoires2018-03-231-26/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This should prevent future mess ups fortunately. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> -- include/linux/hid.h | 52 ++++++++++++++++++++++++++-------------------------- 1 file changed, 26 insertions(+), 26 deletions(-) Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| * | HID: use BIT macro instead of plain integers for flagsBenjamin Tissoires2018-03-231-6/+7
| |/ | | | | | | | | | | | | | | | | | | | | | | | | This can lead to some hairy situation with the developer losing a day or two realizing that 4 should be after 2, not 3. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> -- include/linux/hid.h | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | HID: core: Fix size as type u32Aaron Ma2018-02-161-3/+3
|/ | | | | | | | | | | | When size is negative, calling memset will make segment fault. Declare the size as type u32 to keep memset safe. size in struct hid_report is unsigned, fix return type of hid_report_len to u32. Cc: stable@vger.kernel.org Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: hid-multitouch: support fine-grain orientation reportingWei-Ning Huang2017-12-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The current hid-multitouch driver only allow the report of two orientations, vertical and horizontal. We use the Azimuth orientation usage 0x3F under the Digitizer usage page to report orientation if the device supports it. Changelog: v1 -> v2: - Fix commit message. - Remove resolution reporting for ABS_MT_ORIENTATION. v2 -> v3: - Fix commit message. v3 -> v4: - Fix ABS_MT_ORIENTATION ABS param range. - Don't set ABS_MT_ORIENTATION in ABS_DG_HEIGHT when it is already set by ABS_DG_AZIMUTH. v4 -> v5: - Improve multi-touch-protocol.rst documentation. Signed-off-by: Wei-Ning Huang <wnhuang@chromium.org> Signed-off-by: Wei-Ning Huang <wnhuang@google.com> Reviewed-by: Dmitry Torokhov <dtor@chromium.org> Reviewed-by: Henrik Rydberg <rydberg@bitmath.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: core: remove the absolute need of hid_have_special_driver[]Benjamin Tissoires2017-11-211-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most HID devices behave properly when they are used with hid-generic. Since kernel v4.12, we do not poll for input reports at plug in, so hid-generic should behave properly with all HID devices. There has been a long standing list of HID devices that have a special driver. It used to be just a few, but with time, this list went too big, and we can not ask users to know which HID special driver will pick up their device. We can teach hid-generic to be nice with others. If a device is not explicitly marked with HID_QUIRK_HAVE_SPECIAL_DRIVER, we can allow hid-generic to pick up the device as long as no other loaded HID driver will match the device. When the special driver appears, hid-generic can step back and let the special driver handling the device. In case this special driver is removed, this good old pal of hid-generic will rebind to the device. This basically makes the list hid_have_special_driver[] useless. It still allows to not see a hid-generic driver bound and removed during boot, so we can keep it around. This will also help other people to have a special HID driver without the need of recompiling hid-core. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: quirks: move the list of special devices into a quirkBenjamin Tissoires2017-11-211-0/+1
| | | | | | | | | | | It is better to centralize the information of special devices in one single file. Instead of manually parsing the list of devices that have a special driver or those that need to be ignored, introduce HID_QUIRK_HAVE_SPECIAL_DRIVER and set the correct quirks while fetching those quirks. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: core: move the dynamic quirks handling in coreBenjamin Tissoires2017-11-211-4/+6
| | | | | | | | | usbhid has a list of dynamic quirks in addition to a list of static quirks. There is not much USB specific in that, so move this part of the module in core so we can have one central place for quirks. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* Merge branch 'for-4.15/upstream' into for-linusJiri Kosina2017-11-151-0/+1
|\ | | | | | | | | | | | | | | | | - cp2112: GPIO error handling and Kconfig fixes from Sébastien Szymanski - i2c-hid: fixup / quirk for Apollo-Lake based laptops, from Hans de Goede - Input/Core: add eraser tool support, from Ping Cheng - small assorted code fixes Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| * HID: add comment for power callback in struct hid_ll_driverJaejoong Kim2017-10-021-0/+1
| | | | | | | | | | | | | | There is a missing comment in struct hid_ll_driver. So, add it. Signed-off-by: Jaejoong Kim <climbbb.kim@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | HID: hid-multitouch: forward MSC_TIMESTAMPNicolas Boichat2017-10-051-0/+1
|/ | | | | | | | | | | | | | Computes and forwards the device timestamp according to the specification. Many devices use a 16-bit timestamp field, with a resolution of 100us, therefore rolling around very frequently (every 6.5 seconds). To make sure there is no ambiguity, the timestamp reported to the input stack reset to 0 whenever the time between 2 received events is greater than MAX_TIMESTAMP_INTERVAL (1 second). Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* Merge branch 'for-linus' of ↵Linus Torvalds2017-09-051-2/+16
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid Pull HID update from Jiri Kosina: - Wacom driver fixes/updates (device name generation improvements, touch ring status support) from Jason Gerecke - T100 touchpad support from Hans de Goede - support for batteries driven by HID input reports, from Dmitry Torokhov - Arnd pointed out that driver_lock semaphore is superfluous, as driver core already provides all the necessary concurency protection. Removal patch from Binoy Jayan - logical minimum numbering improvements in sensor-hub driver, from Srinivas Pandruvada - support for Microsoft Win8 Wireless Radio Controls extensions from João Paulo Rechi Vita - assorted small fixes and device ID additions * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (28 commits) HID: prodikeys: constify snd_rawmidi_ops structures HID: sensor: constify platform_device_id HID: input: throttle battery uevents HID: usbmouse: constify usb_device_id and fix space before '[' error HID: usbkbd: constify usb_device_id and fix space before '[' error. HID: hid-sensor-hub: Force logical minimum to 1 for power and report state HID: wacom: Do not completely map WACOM_HID_WD_TOUCHRINGSTATUS usage HID: asus: Add T100CHI bluetooth keyboard dock touchpad support HID: ntrig: constify attribute_group structures. HID: logitech-hidpp: constify attribute_group structures. HID: sensor: constify attribute_group structures. HID: multitouch: constify attribute_group structures. HID: multitouch: use proper symbolic constant for 0xff310076 application HID: multitouch: Support Asus T304UA media keys HID: multitouch: Support HID_GD_WIRELESS_RADIO_CTLS HID: input: optionally use device id in battery name HID: input: map digitizer battery usage HID: Remove the semaphore driver_lock HID: wacom: add USB_HID dependency HID: add ALWAYS_POLL quirk for Logitech 0xc077 ...
| * Merge branch 'for-4.14/wacom' into for-linusJiri Kosina2017-09-051-0/+11
| |\ | | | | | | | | | | | | - name generation improvement for Wacom devices from Jason Gerecke - Kconfig dependency fix for Wacom driver from Arnd Bergmann
| | * HID: introduce hid_is_using_ll_driverJason Gerecke2017-07-271-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although HID itself is transport-agnostic, occasionally a driver may want to interact with the low-level transport that a device is connected through. To do this, we need to know what kind of bus is in use. The first guess may be to look at the 'bus' field of the 'struct hid_device', but this field may be emulated in some cases (e.g. uhid). More ideally, we can check which ll_driver a device is using. This function introduces a 'hid_is_using_ll_driver' function and makes the 'struct hid_ll_driver' of the four most common transports accessible through hid.h. Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Acked-By: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
OpenPOWER on IntegriCloud