summaryrefslogtreecommitdiffstats
path: root/drivers/hid/hid-input.c
Commit message (Collapse)AuthorAgeFilesLines
* HID: core: fix grouping by applicationBenjamin Tissoires2018-09-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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>
* HID: input: fix leaking custom input node nameStefan Agner2018-08-281-0/+1
| | | | | | | | | Make sure to free the custom input node name on disconnect. Cc: stable@vger.kernel.org # v4.18+ Fixes: c554bb045511 ("HID: input: append a suffix matching the application") Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: input: enable Totem on the Dell Canvas 27Benjamin Tissoires2018-07-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'for-4.18/multitouch' into for-linusJiri Kosina2018-06-081-10/+113
|\ | | | | | | | | - improvement of duplicate usage handling in hid-input from Benjamin Tissoires - Win 8.1 precisioun touchpad spec implementation from Benjamin Tissoires
| * HID: input: append a suffix matching the applicationBenjamin Tissoires2018-04-261-8/+59
| | | | | | | | | | | | | | | | 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-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: input: fix battery level reporting on BT miceDmitry Torokhov2018-04-091-7/+17
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | 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/multitouch' into for-linusJiri Kosina2018-04-051-5/+5
|\ | | | | | | 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-5/+5
| | | | | | | | | | | | | | | | | | | | | | 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: Fix hid_report_len usageAaron Ma2018-02-161-1/+2
|/ | | | | | | | | | Follow the change of return type u32 of hid_report_len, fix all the types of variables those get the return value of hid_report_len to u32, and all other code already uses 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-input: Add eraser usage to hidinput_configure_usagePing Cheng2017-10-051-0/+9
| | | | | | | | | Some tablets report eraser usage to indicate the eraser tool tip is touching the surface. But, hidinput_configure_usage didn't support the usage, which led it falls into default as ABS_MISC. Signed-off-by: Ping Cheng <ping.cheng@wacom.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: input: throttle battery ueventsDmitry Torokhov2017-08-151-3/+9
| | | | | | | | | | | The power_supply subsystem tends to emit uevent every time power_supply_changed() is called, so we should call this API only when battery strength reported by the device is actually different from the previous readings, otherwise we'll drown the system in uevents. Fixes: 581c4484769e ("HID: input: map digitizer battery usage") Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: input: optionally use device id in battery nameDmitry Torokhov2017-08-021-1/+3
| | | | | | | | | | | | | | | Manufacturers do not always populate serial number in their devices, so let's fall back to device ID when forming the battery device name. As a result, batteries in devices without serial number will be named like this: hid-0018:2D1F:510E.0001-battery (as opposed to hid--battery for the first one, and failing to create batteries for the subsequent ones). Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: input: map digitizer battery usageDmitry Torokhov2017-08-021-59/+125
| | | | | | | | | | | | | | We already mapped battery strength reports from the generic device control page, but we did not update capacity from input reports, nor we mapped the battery strength report from the digitizer page, so let's implement this now. Batteries driven by the input reports will now start in "unknown" state, and will get updated once we receive first report containing battery strength from the device. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: Microsoft Win8 Wireless Radio Controls cleanupHans de Goede2017-05-221-1/+1
| | | | | | | | | | | Use a better URL for the HUTRR40 Radio HID Usages documentation and use the HID_GD_WIRELESS_RADIO_CTLS define rather then hardcoding a check for 0x0001000c. Fixes: 61df56bef9 ("HID: Add mapping for Microsoft Win8 Wireless Radio Controls extensions") Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: Add mapping for Microsoft Win8 Wireless Radio Controls extensionsHans de Goede2017-05-111-0/+9
| | | | | | | | | | | | | | | | | | | | | | Microsoft has defined some extra HUT codes for the Generic Desktop Page for Wireless Radio controls, see: https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/airplane-mode-radio-management https://web.archive.org/web/20170509144631/https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/airplane-mode-radio-management I've 3 2-in-1 keyboard docks: Dell Venue Pro 11 keyboard dock, HP pavilion x2 keyboard dock and a PEAQ C1010 keyboard dock which have a wireless radio toggle hotkey, which uses the 0x000100c6 HUT code defined in these extensions. This commit adds a mapping for this key, this makes the rfkill toggle hotkey work on the Dell Venue Pro 11 and HP Pavilion X2 keyboards, the PEAQ C1010 keyboard does generate events for the 0x000100c6 HUT code when pressed, but the reported value is always 0. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: clamp input to logical range if no null stateTomasz Kramkowski2017-03-211-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes an issue in drivers/hid/hid-input.c where values outside of the logical range are not clamped when "null state" bit of the input control is not set. This was discussed on the lists [1] and this change stems from the fact due to the ambiguity of the HID specification it might be appropriate to follow Microsoft's own interpretation of the specification. As noted in Microsoft's documentation [2] in the section titled "Required HID usages for digitizers" it is noted that values reported outside the logical range "will be considered as invalid data and the value will be changed to the nearest boundary value (logical min/max)." This patch fixes an issue where the (1292:4745) Innomedia INNEX GENESIS/ATARI reports out of range values for its X and Y axis of the DPad which, due to the null state bit being unset, are forwarded to userspace as is. Now these values will get clamped to the logical range before being forwarded to userspace. This device was also used to test this patch. This patch expands on commit 3f3752705dbd ("HID: reject input outside logical range only if null state is set"). [1]: http://lkml.kernel.org/r/20170307131036.GA853@gaia.local [2]: https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85).asp Signed-off-by: Tomasz Kramkowski <tk@the-tk.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: reject input outside logical range only if null state is setValtteri Heikkilä2017-03-061-0/+1
| | | | | | | | | | | | | | | This patch fixes an issue in drivers/hid/hid-input.c where USB HID control null state flag is not checked upon rejecting inputs outside logical minimum-maximum range. The check should be made according to USB HID specification 1.11, section 6.2.2.5, p.31. The fix will resolve issues with some game controllers, such as: https://bugzilla.kernel.org/show_bug.cgi?id=68621 [tk@the-tk.com: shortened and fixed spelling in commit message] Signed-off-by: Valtteri Heikkilä <rnd@nic.fi> Signed-off-by: Tomasz Kramkowski <tk@the-tk.com> Acked-By: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
*-. Merge branches 'for-4.10/asus', 'for-4.10/cp2112', ↵Jiri Kosina2016-12-141-41/+55
|\ \ | | | | | | | | | 'for-4.10/i2c-hid-nopower', 'for-4.10/intel-ish', 'for-4.10/mayflash', 'for-4.10/microsoft-surface-3', 'for-4.10/multitouch', 'for-4.10/sony', 'for-4.10/udraw-ps3', 'for-4.10/upstream' and 'for-4.10/wacom/generic' into for-linus
| | * HID: input: Recognize ABS_WHEEL in hidinput_calc_abs_resJason Gerecke2016-10-201-0/+1
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "Steering" usage (HID_UP_SIMULATION | 0xc8) is defined in HUT 1.12 as follows: "A steering wheel is a single degree-of-freedom device that rotates about an axis. The zero position is always the neutral or 'straight ahead' position, with positive values turning clockwise and negative values turning counterclockwise. If the Coordinate Values Wrap attribute is set, the steering wheel can be turned past 360 degrees." The hidinput_configure_usage function canonically maps this usage to the ABS_WHEEL axis, but hidinput_calc_abs_res does not recognize this axis as one for which it can calculate a resolution. This effectively prevents wheels from being assigned a proper resolution that userspace can use to determine the precise angle of input. This commit adds ABS_WHEEL as a rotational axis to hidinput_calc_abs_res. Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| * HID: input: rework HID_QUIRK_MULTI_INPUTBenjamin Tissoires2016-11-281-41/+54
|/ | | | | | | | | | | | | | | | | | | The purpose of HID_QUIRK_MULTI_INPUT is to have an input device per report id. This is useful when the HID device presents several HID collections of different device types. The current implementation of hid-input creates one input node per id per type (input or output). This is problematic for the LEDs of a keyboard as they are often set through an output report. The current code creates one input node with all the keyboard keys, and one other with only the LEDs. To solve this, we use a two-passes way: - first, we initialize all input nodes and associate one per report id - then, we register all the input nodes Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
*-. Merge branches 'for-4.8/upstream-fixes', 'for-4.9/alps', ↵Jiri Kosina2016-10-071-0/+9
|\ \ | | | | | | | | | 'for-4.9/hid-input', 'for-4.9/intel-ish', 'for-4.9/kye-uclogic-waltop-fixes', 'for-4.9/logitech', 'for-4.9/sony', 'for-4.9/upstream' and 'for-4.9/wacom' into for-linus
| | * HID: input: ignore System Control application usages if not System ControlsBenjamin Tissoires2016-09-191-0/+9
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Microsoft is reusing its report descriptor again and again, and part of it looks like this: 0x05, 0x01, // Usage Page (Generic Desktop) 299 0x09, 0x80, // Usage (System Control) 301 0xa1, 0x01, // Collection (Application) 303 0x85, 0x03, // Report ID (3) 305 0x19, 0x00, // Usage Minimum (0) 307 0x29, 0xff, // Usage Maximum (255) 309 0x15, 0x00, // Logical Minimum (0) 311 0x26, 0xff, 0x00, // Logical Maximum (255) 313 0x81, 0x00, // Input (Data,Arr,Abs) 316 0xc0, // End Collection 318 While there is nothing wrong in term of processing, we do however blindly map the full usage range (it's an array) from 0x00 to 0xff, which creates some interesting axis, like ABS_X|Y, and a bunch of ABS_MISC + n. While libinput and other stacks don't care that much (we can detect them), joydev is very happy and attaches itself to the mouse or keyboard. The problem is that joydev now handles the device as a joystick, but given that we have a HID array, it sets all the ABS_* values to 0. And in its world, 0 means -32767 (minimum value), which sends spurious events to games (think Steam). It looks like hid-microsoft tries to tackle the very same problem with its .report_fixup callback. But fixing the report descriptor is an endless task and is quite obfuscated. So take the hammer, and decide that if the application is meant to be System Control, any other usage not in the System Control range should be ignored. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1325354 Link: https://bugzilla.kernel.org/show_bug.cgi?id=28912 Link: https://github.com/ValveSoftware/steam-for-linux/issues/3384 Link: https://bugzilla.redhat.com/show_bug.cgi?id=1325354 Link: https://bugzilla.kernel.org/show_bug.cgi?id=37982 Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* / HID: input: add mic mute key on HP slim keyboardAceLan Kao2016-08-051-0/+1
|/ | | | | | | | | | | | | | | | Add MIC mute key which is found on HP Business Slim Keyboard T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 23 Spd=1.5 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=03f0 ProdID=2f4a Rev=00.10 S: Manufacturer=Chicony S: Product=HP Business Slim Keyboard C: #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
*-. Merge branches 'for-4.4/upstream-fixes', 'for-4.5/async-suspend', ↵Jiri Kosina2016-01-141-5/+16
|\ \ | | | | | | | | | 'for-4.5/container-of-cleanups', 'for-4.5/core', 'for-4.5/i2c-hid', 'for-4.5/logitech', 'for-4.5/multitouch', 'for-4.5/sony', 'for-4.5/upstream' and 'for-4.5/wacom' into for-linus
| | * HID: input: ignore the battery in OKLICK Laser BTmouseAlexander E. Patrakov2015-12-181-5/+12
| |/ |/| | | | | | | | | | | | | This mouse, when asked about the battery, ceases to report movements and clicks. So just don't ask. Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| * HID: Add vendor specific usage pages for Logitech G920Simon Wood2015-11-201-0/+4
|/ | | | | | | | | | | | The Logitech G920 uses a couple of vendor specific usage pages, which results in incorrect number of axis/buttons being detected. This patch adds these pages to the 'ignore' list. Reported-by: Elias Vanderstuyft <elias.vds@gmail.com> Signed-off-by: Simon Wood <simon@mungewell.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: hid-input: allow input_configured callback return errorsDmitry Torokhov2015-11-051-4/+6
| | | | | | | | | | | | | | | | 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>
* Merge branches 'for-4.2/upstream-fixes-devm-fixed' and 'for-4.3/upstream' ↵Jiri Kosina2015-09-011-1/+4
|\ | | | | | | into for-linus
| * HID: input: call input_sync() when automatically releasing a keyDmitry Torokhov2015-07-101-1/+4
| | | | | | | | | | | | | | | | | | | | | | We need to emit EV_SYN/SYN_REPORT between key press and release, otherwise userspace is allowed to "swallow" the event. [jkosina@suse.com: Dmitry says that he's observing this behavior with Plantronics headset] Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
* | HID: hid-input: Fix accessing freed memory during device disconnectKrzysztof Kozlowski2015-08-041-2/+5
|/ | | | | | | | | | | | | | | | | | | | | During unbinding the driver was dereferencing a pointer to memory already freed by power_supply_unregister(). Driver was freeing its internal description of battery through pointers stored in power_supply structure. However, because the core owns the power supply instance, after calling power_supply_unregister() this memory is freed and the driver cannot access these members. Fix this by storing the pointer to internal description of battery in a local variable before calling power_supply_unregister(), so the pointer remains valid. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reported-by: H.J. Lu <hjl.tools@gmail.com> Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core") Cc: <stable@vger.kernel.org> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
* HID: hid-input: Fix coding style issueJames C Boyd2015-05-281-1/+2
| | | | | | | This line is too long; split it up. Signed-off-by: James C Boyd <jcboyd.dev@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: hid-input: Simplify conditional expressionJames C Boyd2015-05-281-1/+1
| | | | | | | | There are too many bangs in this conditional; therefore remove them while still maintaining the same logic. Signed-off-by: James C Boyd <jcboyd.dev@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: hid-input: Add parentheses to quell gcc warningJames C Boyd2015-05-281-1/+1
| | | | | | | | GCC reports a -Wlogical-not-parentheses warning here; therefore add parentheses to shut it up and to express our intent more. Signed-off-by: James C Boyd <jcboyd.dev@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* Merge branch 'for-linus' of ↵Linus Torvalds2015-04-141-0/+23
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid Pull HID updates from Jiri Kosina: - quite a few firmware fixes for RMI driver by Andrew Duggan - huion and uclogic drivers have been substantially overlaping in functionality laterly. This redundancy is fixed by hid-huion driver being merged into hid-uclogic; work done by Benjamin Tissoires and Nikolai Kondrashov - i2c-hid now supports ACPI GPIO interrupts; patch from Mika Westerberg - Some of the quirks, that got separated into individual drivers, have historically had EXPERT dependency. As HID subsystem matured (as well as the individual drivers), this made less and less sense. This dependency is now being removed by patch from Jean Delvare - Logitech lg4ff driver received a couple of improvements for mode switching, by Michal Malý - multitouch driver now supports clickpads, patches by Benjamin Tissoires and Seth Forshee - hid-sensor framework received a substantial update; namely support for Custom and Generic pages is being added; work done by Srinivas Pandruvada - wacom driver received substantial update; it now supports i2c-conntected devices (Mika Westerberg), Bamboo PADs are now properly supported (Benjamin Tissoires), much improved battery reporting (Jason Gerecke) and pen proximity cleanups (Ping Cheng) - small assorted fixes and device ID additions * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (68 commits) HID: sensor: Update document for custom sensor HID: sensor: Custom and Generic sensor support HID: debug: fix error handling in hid_debug_events_read() Input - mt: Fix input_mt_get_slot_by_key HID: logitech-hidpp: fix error return code HID: wacom: Add support for Cintiq 13HD Touch HID: logitech-hidpp: add a module parameter to keep firmware gestures HID: usbhid: yet another mouse with ALWAYS_POLL HID: usbhid: more mice with ALWAYS_POLL HID: wacom: set stylus_in_proximity before checking touch_down HID: wacom: use wacom_wac_finger_count_touches to set touch_down HID: wacom: remove hardcoded WACOM_QUIRK_MULTI_INPUT HID: pidff: effect can't be NULL HID: add quirk for PIXART OEM mouse used by HP HID: add HP OEM mouse to quirk ALWAYS_POLL HID: wacom: ask for a in-prox report when it was missed HID: hid-sensor-hub: Fix sparse warning HID: hid-sensor-hub: fix attribute read for logical usage id HID: plantronics: fix Kconfig default HID: pidff: support more than one concurrent effect ...
| * HID: map telephony usage pageDmitry Torokhov2015-03-041-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently HID code maps usages from telephony page into BTN_0, BTN_1, etc keys which get interpreted by mousedev and userspace as left/right/middle button clicks, which is not really helpful. This change adds mappings for usages that have corresponding input event definitions, and leaves the rest unmapped. This can be changed when there are userspace consumers for more telephony usages. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | HID: input: Fix NULL pointer dereference when power_supply_register failsKrzysztof Kozlowski2015-03-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | Do not call power_supply_powers() if power_supply_register() failed earlier. This fixes possible NULL pointer dereference by power_supply_powers() in such case. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power_supply: Change ownership from driver to coreKrzysztof Kozlowski2015-03-131-21/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change the ownership of power_supply structure from each driver implementing the class to the power supply core. The patch changes power_supply_register() function thus all drivers implementing power supply class are adjusted. Each driver provides the implementation of power supply. However it should not be the owner of power supply class instance because it is exposed by core to other subsystems with power_supply_get_by_name(). These other subsystems have no knowledge when the driver will unregister the power supply. This leads to several issues when driver is unbound - mostly because user of power supply accesses freed memory. Instead let the core own the instance of struct 'power_supply'. Other users of this power supply will still access valid memory because it will be freed when device reference count reaches 0. Currently this means "it will leak" but power_supply_put() call in next patches will solve it. This solves invalid memory references in following race condition scenario: Thread 1: charger manager Thread 2: power supply driver, used by charger manager THREAD 1 (charger manager) THREAD 2 (power supply driver) ========================== ============================== psy = power_supply_get_by_name() Driver unbind, .remove power_supply_unregister() Device fully removed psy->get_property() The 'get_property' call is executed in invalid context because the driver was unbound and struct 'power_supply' memory was freed. This could be observed easily with charger manager driver (here compiled with max17040 fuel gauge): $ cat /sys/devices/virtual/power_supply/cm-battery/capacity & $ echo "1-0036" > /sys/bus/i2c/drivers/max17040/unbind [ 55.725123] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 55.732584] pgd = d98d4000 [ 55.734060] [00000000] *pgd=5afa2831, *pte=00000000, *ppte=00000000 [ 55.740318] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM [ 55.746210] Modules linked in: [ 55.749259] CPU: 1 PID: 2936 Comm: cat Tainted: G W 3.19.0-rc1-next-20141226-00048-gf79f475f3c44-dirty #1496 [ 55.760190] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 55.766270] task: d9b76f00 ti: daf54000 task.ti: daf54000 [ 55.771647] PC is at 0x0 [ 55.774182] LR is at charger_get_property+0x2f4/0x36c [ 55.779201] pc : [<00000000>] lr : [<c034b0b4>] psr: 60000013 [ 55.779201] sp : daf55e90 ip : 00000003 fp : 00000000 [ 55.790657] r10: 00000000 r9 : c06e2878 r8 : d9b26c68 [ 55.795865] r7 : dad81610 r6 : daec7410 r5 : daf55ebc r4 : 00000000 [ 55.802367] r3 : 00000000 r2 : daf55ebc r1 : 0000002a r0 : d9b26c68 [ 55.808879] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 55.815994] Control: 10c5387d Table: 598d406a DAC: 00000015 [ 55.821723] Process cat (pid: 2936, stack limit = 0xdaf54210) [ 55.827451] Stack: (0xdaf55e90 to 0xdaf56000) [ 55.831795] 5e80: 60000013 c01459c4 0000002a c06f8ef8 [ 55.839956] 5ea0: db651000 c06f8ef8 daebac00 c04cb668 daebac08 c0346864 00000000 c01459c4 [ 55.848115] 5ec0: d99eaa80 c06f8ef8 00000fff 00001000 db651000 c027f25c c027f240 d99eaa80 [ 55.856274] 5ee0: d9a06c00 c0146218 daf55f18 00001000 d99eaa80 db4c18c0 00000001 00000001 [ 55.864468] 5f00: daf55f80 c0144c78 c0144c54 c0107f90 00015000 d99eaab0 00000000 00000000 [ 55.872603] 5f20: 000051c7 00000000 db4c18c0 c04a9370 00015000 00001000 daf55f80 00001000 [ 55.880763] 5f40: daf54000 00015000 00000000 c00e53dc db4c18c0 c00e548c 0000000d 00008124 [ 55.888937] 5f60: 00000001 00000000 00000000 db4c18c0 db4c18c0 00001000 00015000 c00e5550 [ 55.897099] 5f80: 00000000 00000000 00001000 00001000 00015000 00000003 00000003 c000f364 [ 55.905239] 5fa0: 00000000 c000f1a0 00001000 00015000 00000003 00015000 00001000 0001333c [ 55.913399] 5fc0: 00001000 00015000 00000003 00000003 00000002 00000000 00000000 00000000 [ 55.921560] 5fe0: 7fffe000 be999850 0000a225 b6f3c19c 60000010 00000003 00000000 00000000 [ 55.929744] [<c034b0b4>] (charger_get_property) from [<c0346864>] (power_supply_show_property+0x48/0x20c) [ 55.939286] [<c0346864>] (power_supply_show_property) from [<c027f25c>] (dev_attr_show+0x1c/0x48) [ 55.948130] [<c027f25c>] (dev_attr_show) from [<c0146218>] (sysfs_kf_seq_show+0x84/0x104) [ 55.956298] [<c0146218>] (sysfs_kf_seq_show) from [<c0144c78>] (kernfs_seq_show+0x24/0x28) [ 55.964536] [<c0144c78>] (kernfs_seq_show) from [<c0107f90>] (seq_read+0x1b0/0x484) [ 55.972172] [<c0107f90>] (seq_read) from [<c00e53dc>] (__vfs_read+0x18/0x4c) [ 55.979188] [<c00e53dc>] (__vfs_read) from [<c00e548c>] (vfs_read+0x7c/0x100) [ 55.986304] [<c00e548c>] (vfs_read) from [<c00e5550>] (SyS_read+0x40/0x8c) [ 55.993164] [<c00e5550>] (SyS_read) from [<c000f1a0>] (ret_fast_syscall+0x0/0x48) [ 56.000626] Code: bad PC value [ 56.011652] ---[ end trace 7b64343fbdae8ef1 ]--- Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> [for the nvec part] Reviewed-by: Marc Dietrich <marvin24@gmx.de> [for compal-laptop.c] Acked-by: Darren Hart <dvhart@linux.intel.com> [for the mfd part] Acked-by: Lee Jones <lee.jones@linaro.org> [for the hid part] Acked-by: Jiri Kosina <jkosina@suse.cz> [for the acpi part] Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* | power_supply: Move run-time configuration to separate structureKrzysztof Kozlowski2015-03-131-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add new structure 'power_supply_config' for holding run-time initialization data like of_node, supplies and private driver data. The power_supply_register() function is changed so all power supply drivers need updating. When registering the power supply this new 'power_supply_config' should be used instead of directly initializing 'struct power_supply'. This allows changing the ownership of power_supply structure from driver to the power supply core in next patches. When a driver does not use of_node or supplies then it should use NULL as config. If driver uses of_node or supplies then it should allocate config on stack and initialize it with proper values. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Pavel Machek <pavel@ucw.cz> [for the nvec part] Reviewed-by: Marc Dietrich <marvin24@gmx.de> [for drivers/platform/x86/compal-laptop.c] Reviewed-by: Darren Hart <dvhart@linux.intel.com> [for drivers/hid/*] Reviewed-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sebastian Reichel <sre@kernel.org>
*---. Merge branches 'for-3.19/upstream-fixes', 'for-3.20/apple', ↵Jiri Kosina2015-02-091-3/+23
|\ \ \ | | | | | | | | | | | | 'for-3.20/betop', 'for-3.20/lenovo', 'for-3.20/logitech', 'for-3.20/rmi', 'for-3.20/upstream' and 'for-3.20/wacom' into for-linus
| | | * HID: fixup the conflicting keyboard mappings quirkJiri Kosina2015-01-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ignore check that got added in 6ce901eb61 ("HID: input: fix confusion on conflicting mappings") needs to properly check for VARIABLE reports as well (ARRAY reports should be ignored), otherwise legitimate keyboards might break. Cc: <stable@vger.kernel.org> Fixes: 6ce901eb61 ("HID: input: fix confusion on conflicting mappings") Reported-by: Fredrik Hallenberg <megahallon@gmail.com> Reported-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| | | * HID: input: fix confusion on conflicting mappingsDavid Herrmann2015-01-061-0/+16
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On an PC-101/103/104 keyboard (American layout) the 'Enter' key and its neighbours look like this: +---+ +---+ +-------+ | 1 | | 2 | | 5 | +---+ +---+ +-------+ +---+ +-----------+ | 3 | | 4 | +---+ +-----------+ On a PC-102/105 keyboard (European layout) it looks like this: +---+ +---+ +-------+ | 1 | | 2 | | | +---+ +---+ +-+ 4 | +---+ +---+ | | | 3 | | 5 | | | +---+ +---+ +-----+ (Note that the number of keys is the same, but key '5' is moved down and the shape of key '4' is changed. Keys '1' to '3' are exactly the same.) The keys 1-4 report the same scan-code in HID in both layouts, even though the keysym they produce is usually different depending on the XKB-keymap used by user-space. However, key '5' (US 'backslash'/'pipe') reports 0x31 for the upper layout and 0x32 for the lower layout, as defined by the HID spec. This is highly confusing as the linux-input API uses a single keycode for both. So far, this was never a problem as there never has been a keyboard with both of those keys present at the same time. It would have to look something like this: +---+ +---+ +-------+ | 1 | | 2 | | x31 | +---+ +---+ +-------+ +---+ +---+ +-----+ | 3 | |x32| | 4 | +---+ +---+ +-----+ HID can represent such a keyboard, but the linux-input API cannot. Furthermore, any user-space mapping would be confused by this and, luckily, no-one ever produced such hardware. Now, the HID input layer fixed this mess by mapping both 0x31 and 0x32 to the same keycode (KEY_BACKSLASH==0x2b). As only one of both physical keys is present on a hardware, this works just fine. Lets introduce hardware-vendors into this: ------------------------------------------ Unfortunately, it seems way to expensive to produce a different device for American and European layouts. Therefore, hardware-vendors put both keys, (0x31 and 0x32) on the same keyboard, but only one of them is hooked up to the physical button, the other one is 'dead'. This means, they can use the same hardware, with a different button-layout and automatically produce the correct HID events for American *and* European layouts. This is unproblematic for normal keyboards, as the 'dead' key will never report any KEY-DOWN events. But RollOver keyboards send the whole matrix on each key-event, allowing n-key roll-over mode. This means, we get a 0x31 and 0x32 event on each key-press. One of them will always be 0, the other reports the real state. As we map both to the same keycode, we will get spurious key-events, even though the real key-state never changed. The easiest way would be to blacklist 'dead' keys and never handle those. We could simply read the 'country' tag of USB devices and blacklist either key according to the layout. But... hardware vendors... want the same device for all countries and thus many of them set 'country' to 0 for all devices. Meh.. So we have to deal with this properly. As we cannot know which of the keys is 'dead', we either need a heuristic and track those keys, or we simply make use of our value-tracking for HID fields. We simply ignore HID events for absolute data if the data didn't change. As HID tracks events on the HID level, we haven't done the keycode translation, yet. Therefore, the 'dead' key is tracked independently of the real key, therefore, any events on it will be ignored. This patch simply discards any HID events for absolute data if it didn't change compared to the last report. We need to ignore relative and buffered-byte reports for obvious reasons. But those cannot be affected by this bug, so we're fine. Preferably, we'd do this filtering on the HID-core level. But this might break a lot of custom drivers, if they do not follow the HID specs. Therefore, we do this late in hid-input just before we inject it into the input layer (which does the exact same filtering, but on the keycode level). If this turns out to break some devices, we might have to limit filtering to EV_KEY events. But lets try to do the Right Thing first, and properly filter any absolute data that didn't change. This patch is tagged for 'stable' as it fixes a lot of n-key RollOver hardware. We might wanna wait with backporting for a while, before we know it doesn't break anything else, though. Cc: <stable@vger.kernel.org> Reported-by: Adam Goode <adam@spicenitz.org> Reported-by: Fredrik Hallenberg <megahallon@gmail.com> Tested-by: Fredrik Hallenberg <megahallon@gmail.com> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| * / HID: apple: fix battery support for the 2009 ANSI wireless keyboardRoss Skaliotis2015-01-061-3/+6
| |/ | | | | | | | | | | | | | | Enabled quirks necessary for correct battery capacity reporting. Cleaned up surrounding style. Signed-off-by: Ross Skaliotis <rskaliotis@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* / HID: add battery quirk for USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO keyboardKarl Relton2014-12-171-0/+3
|/ | | | | | | | | | Apple bluetooth wireless keyboard (sold in UK) has always reported zero for battery strength no matter what condition the batteries are actually in. With this patch applied (applying same quirk as other Apple keyboards), the battery strength is now correctly reported. Signed-off-by: Karl Relton <karllinuxtest.relton@ntlworld.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
*-----. Merge branches 'for-3.19/hid-report-len', 'for-3.19/i2c-hid', ↵Jiri Kosina2014-12-121-1/+1
|\ \ \ \ | | | | | | | | | | | | | | | 'for-3.19/lenovo', 'for-3.19/logitech', 'for-3.19/microsoft', 'for-3.19/plantronics', 'for-3.19/rmi', 'for-3.19/sony' and 'for-3.19/wacom' into for-linus
| * | | | HID: make hid_report_len as a static inline function in hid.hMathieu Magnaudet2014-12-011-1/+1
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In several hid drivers it is necessary to calculate the length of an hid_report. This patch exports the existing static function hid_report_len of hid-core.c as an inline function in hid.h Signed-off-by: Mathieu Magnaudet <mathieu.magnaudet@enac.fr> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | | | Merge branches 'for-3.18/upstream-fixes' and 'for-3.19/upstream' into for-linusJiri Kosina2014-12-121-1/+1
|\ \ \ \ | |/ / / |/| / / | |/ / | | | Conflicts: drivers/hid/hid-input.c
| * / HID: input: Map unknown consumer page codes to KEY_UNKNOWNHans de Goede2014-10-221-1/+1
| |/ | | | | | | | | | | | | | | | | | | Currently unknown consumer page codes are ignored, which means that they cannot later be mapped from userspace using udev / hwdb. Map them to KEY_UNKNOWN, so that userspace can remap them for keyboards which make up their own consumer page codes. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-06 16:56:32 +0000