summaryrefslogtreecommitdiffstats
path: root/drivers/hid
Commit message (Collapse)AuthorAgeFilesLines
* HID: hidraw: Fix crash on HIDIOCGFEATURE with a destroyed deviceRodrigo Rivas Costa2018-04-241-0/+5
| | | | | | | | | | | | | | | | | | commit a955358d54695e4ad9f7d6489a7ac4d69a8fc711 upstream. Doing `ioctl(HIDIOCGFEATURE)` in a tight loop on a hidraw device and then disconnecting the device, or unloading the driver, can cause a NULL pointer dereference. When a hidraw device is destroyed it sets 0 to `dev->exist`. Most functions check 'dev->exist' before doing its work, but `hidraw_get_report()` was missing that check. Cc: stable@vger.kernel.org Signed-off-by: Rodrigo Rivas Costa <rodrigorivascosta@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: i2c-hid: fix size check and type usageAaron Ma2018-04-241-6/+7
| | | | | | | | | | | | | | | commit ac75a041048b8c1f7418e27621ca5efda8571043 upstream. When convert char array with signed int, if the inbuf[x] is negative then upper bits will be set to 1. Fix this by using u8 instead of char. ret_size has to be at least 3, hid_input_report use it after minus 2 bytes. Cc: stable@vger.kernel.org Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: elo: clear BTN_LEFT mappingJiri Kosina2018-03-221-0/+6
| | | | | | | | | | | | | | [ Upstream commit 9abd04af951e5734c9d5cfee9b49790844b734cf ] ELO devices have one Button usage in GenDesk field, which makes hid-input map it to BTN_LEFT; that confuses userspace, which then considers the device to be a mouse/touchpad instead of touchscreen. Fix that by unmapping BTN_LEFT and keeping only BTN_TOUCH in place. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: clamp input to logical range if no null stateTomasz Kramkowski2018-03-221-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit c3883fe06488a483658ba5d849b70e49bee15e7c ] 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> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: reject input outside logical range only if null state is setValtteri Heikkilä2018-03-221-0/+1
| | | | | | | | | | | | | | | | | | | [ Upstream commit 3f3752705dbd50b66b66ad7b4d54fe33d2f746ed ] 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> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: xinmo: fix for out of range for THT 2P arcade controller.Peter Stein2017-12-253-0/+3
| | | | | | | | | | | | | | | [ Upstream commit 9257821c5a1dc57ef3a37f7cbcebaf548395c964 ] There is a new clone of the XIN MO arcade controller which has same issue with out of range like the original. This fix will solve the issue where 2 directions on the joystick are not recognized by the new THT 2P arcade controller with device ID 0x75e1. In details the new device ID is added the hid-id list and the hid-xinmo source code. Signed-off-by: Peter Stein <peter@stuntstein.dk> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: usbhid: fix out-of-bounds bugJaejoong Kim2017-10-181-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit f043bfc98c193c284e2cd768fefabe18ac2fed9b upstream. The hid descriptor identifies the length and type of subordinate descriptors for a device. If the received hid descriptor is smaller than the size of the struct hid_descriptor, it is possible to cause out-of-bounds. In addition, if bNumDescriptors of the hid descriptor have an incorrect value, this can also cause out-of-bounds while approaching hdesc->desc[n]. So check the size of hid descriptor and bNumDescriptors. BUG: KASAN: slab-out-of-bounds in usbhid_parse+0x9b1/0xa20 Read of size 1 at addr ffff88006c5f8edf by task kworker/1:2/1261 CPU: 1 PID: 1261 Comm: kworker/1:2 Not tainted 4.14.0-rc1-42251-gebb2c2437d80 #169 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:16 dump_stack+0x292/0x395 lib/dump_stack.c:52 print_address_description+0x78/0x280 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 kasan_report+0x22f/0x340 mm/kasan/report.c:409 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427 usbhid_parse+0x9b1/0xa20 drivers/hid/usbhid/hid-core.c:1004 hid_add_device+0x16b/0xb30 drivers/hid/hid-core.c:2944 usbhid_probe+0xc28/0x1100 drivers/hid/usbhid/hid-core.c:1369 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361 really_probe drivers/base/dd.c:413 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523 device_add+0xd0b/0x1660 drivers/base/core.c:1835 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266 really_probe drivers/base/dd.c:413 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523 device_add+0xd0b/0x1660 drivers/base/core.c:1835 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457 hub_port_connect drivers/usb/core/hub.c:4903 hub_port_connect_change drivers/usb/core/hub.c:5009 port_event drivers/usb/core/hub.c:5115 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119 worker_thread+0x221/0x1850 kernel/workqueue.c:2253 kthread+0x3a1/0x470 kernel/kthread.c:231 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431 Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Jaejoong Kim <climbbb.kim@gmail.com> Tested-by: Andrey Konovalov <andreyknvl@google.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: i2c-hid: allocate hid buffers for real worst caseAdrian Salido2017-10-121-1/+2
| | | | | | | | | | | | | | | | commit 8320caeeffdefec3b58b9d4a7ed8e1079492fe7b upstream. The buffer allocation is not currently accounting for an extra byte for the report id. This can cause an out of bounds access in function i2c_hid_set_or_send_report() with reportID > 15. Signed-off-by: Adrian Salido <salidoa@google.com> Reviewed-by: Benson Leung <bleung@chromium.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: core: prevent out-of-bound readingsBenjamin Tissoires2017-05-201-0/+3
| | | | | | | | | | | | | | | | | commit 50220dead1650609206efe91f0cc116132d59b3f upstream. Plugging a Logitech DJ receiver with KASAN activated raises a bunch of out-of-bound readings. The fields are allocated up to MAX_USAGE, meaning that potentially, we do not have enough fields to fit the incoming values. Add checks and silence KASAN. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Amit Pundir <amit.pundir@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: usbhid: add ATEN CS962 to list of quirky devicesOliver Neukum2017-04-182-0/+2
| | | | | | | | | | | | commit cf0ea4da4c7df11f7a508b2f37518e0f117f3791 upstream. Like many similar devices it needs a quirk to work. Issuing the request gets the device into an irrecoverable state. Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: hid-input: Add parentheses to quell gcc warningJames C Boyd2017-02-081-1/+1
| | | | | | | | | | | | commit 09a5c34e8d6b05663ec4c3d22b1fbd9fec89aaf9 upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: uhid: fix timeout when probe races with IORoderick Colenbrander2016-08-221-9/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 67f8ecc550b5bda03335f845dc869b8501d25fd0 ] Many devices use userspace bluetooth stacks like BlueZ or Bluedroid in combination with uhid. If any of these stacks is used with a HID device for which the driver performs a HID request as part .probe (or technically another HID operation), this results in a deadlock situation. The deadlock results in a 5 second timeout for I/O operations in HID drivers, so isn't fatal, but none of the I/O operations have a chance of succeeding. The root cause for the problem is that uhid only allows for one request to be processed at a time per uhid instance and locks out other operations. This means that if a user space is creating a new HID device through 'UHID_CREATE', which ultimately triggers '.probe' through the HID layer. Then any HID request e.g. a read for calibration data would trigger a HID operation on uhid again, but it won't go out to userspace, because it is still stuck in UHID_CREATE. In addition bluetooth stacks are typically single threaded, so they wouldn't be able to handle any requests while waiting on uhid. Lucikly the UHID spec is somewhat flexible and allows for fixing the issue, without breaking user space. The idea which the patch implements as discussed with David Herrmann is to decouple adding of a hid device (which triggers .probe) from UHID_CREATE. The work will kick off roughly once UHID_CREATE completed (or else will wait a tiny bit of time in .probe for a lock). A HID driver has to call HID to call 'hid_hw_start()' as part of .probe once it is ready for I/O, which triggers UHID_START to user space. Any HID operations should function now within .probe and won't deadlock because userspace is stuck on UHID_CREATE. We verified this patch on Bluedroid with Android 6.0 and on desktop Linux with BlueZ stacks. Prior to the patch they had the deadlock issue. [jkosina@suse.cz: reword subject] Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com> Cc: stable@vger.kernel.org Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
* HID: logitech: fix Dual Action gamepad supportGrazvydas Ignotas2016-07-121-0/+1
| | | | | | | | | | | | | | | | [ Upstream commit 5d74325a2201376a95520a4a38a1ce2c65761c49 ] The patch that added Logitech Dual Action gamepad support forgot to update the special driver list for the device. This caused the logitech driver not to probe unless kernel module load order was favorable. Update the special driver list to fix it. Thanks to Simon Wood for the idea. Cc: Vitaly Katraew <zawullon@gmail.com> Fixes: 56d0c8b7c8fb ("HID: add support for Logitech Dual Action gamepads") Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: hiddev: validate num_values for HIDIOCGUSAGES, HIDIOCSUSAGES commandsScott Bauer2016-07-121-5/+5
| | | | | | | | | | | | | | [ Upstream commit 93a2001bdfd5376c3dc2158653034c20392d15c5 ] This patch validates the num_values parameter from userland during the HIDIOCGUSAGES and HIDIOCSUSAGES commands. Previously, if the report id was set to HID_REPORT_ID_UNKNOWN, we would fail to validate the num_values parameter leading to a heap overflow. Cc: stable@vger.kernel.org Signed-off-by: Scott Bauer <sbauer@plzdonthack.me> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: elo: kill not flush the workOliver Neukum2016-07-111-1/+1
| | | | | | | | | | | | | [ Upstream commit ed596a4a88bd161f868ccba078557ee7ede8a6ef ] Flushing a work that reschedules itself is not a sensible operation. It needs to be killed. Failure to do so leads to a kernel panic in the timer code. CC: stable@vger.kernel.org Signed-off-by: Oliver Neukum <ONeukum@suse.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: usbhid: fix inconsistent reset/resume/reset-resume behaviorAlan Stern2016-04-201-36/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 972e6a993f278b416a8ee3ec65475724fc36feb2 ] The usbhid driver has inconsistently duplicated code in its post-reset, resume, and reset-resume pathways. reset-resume doesn't check HID_STARTED before trying to restart the I/O queues. resume fails to clear the HID_SUSPENDED flag if HID_STARTED isn't set. resume calls usbhid_restart_queues() with usbhid->lock held and the others call it without holding the lock. The first item in particular causes a problem following a reset-resume if the driver hasn't started up its I/O. URB submission fails because usbhid->urbin is NULL, and this triggers an unending reset-retry loop. This patch fixes the problem by creating a new subroutine, hid_restart_io(), to carry out all the common activities. It also adds some checks that were missing in the original code: After a reset, there's no need to clear any halted endpoints. After a resume, if a reset is pending there's no need to restart any I/O until the reset is finished. After a resume, if the interrupt-IN endpoint is halted there's no need to submit the input URB until the halt has been cleared. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Daniel Fraga <fragabr@gmail.com> Tested-by: Daniel Fraga <fragabr@gmail.com> CC: <stable@vger.kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: i2c-hid: fix OOB write in i2c_hid_set_or_send_report()Dmitry Torokhov2016-04-181-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 3b654288b196ceaa156029d9457ccbded0489b98 ] Even though hid_hw_* checks that passed in data_len is less than HID_MAX_BUFFER_SIZE it is not enough, as i2c-hid does not necessarily allocate buffers of HID_MAX_BUFFER_SIZE but rather checks all device reports and select largest size. In-kernel users normally just send as much data as report needs, so there is no problem, but hidraw users can do whatever they please: BUG: KASAN: slab-out-of-bounds in memcpy+0x34/0x54 at addr ffffffc07135ea80 Write of size 4101 by task syz-executor/8747 CPU: 2 PID: 8747 Comm: syz-executor Tainted: G BU 3.18.0 #37 Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT) Call trace: [<ffffffc00020ebcc>] dump_backtrace+0x0/0x258 arch/arm64/kernel/traps.c:83 [<ffffffc00020ee40>] show_stack+0x1c/0x2c arch/arm64/kernel/traps.c:172 [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffc001958114>] dump_stack+0x90/0x140 lib/dump_stack.c:50 [< inline >] print_error_description mm/kasan/report.c:97 [< inline >] kasan_report_error mm/kasan/report.c:278 [<ffffffc0004597dc>] kasan_report+0x268/0x530 mm/kasan/report.c:305 [<ffffffc0004592e8>] __asan_storeN+0x20/0x150 mm/kasan/kasan.c:718 [<ffffffc0004594e0>] memcpy+0x30/0x54 mm/kasan/kasan.c:299 [<ffffffc001306354>] __i2c_hid_command+0x2b0/0x7b4 drivers/hid/i2c-hid/i2c-hid.c:178 [< inline >] i2c_hid_set_or_send_report drivers/hid/i2c-hid/i2c-hid.c:321 [<ffffffc0013079a0>] i2c_hid_output_raw_report.isra.2+0x3d4/0x4b8 drivers/hid/i2c-hid/i2c-hid.c:589 [<ffffffc001307ad8>] i2c_hid_output_report+0x54/0x68 drivers/hid/i2c-hid/i2c-hid.c:602 [< inline >] hid_hw_output_report include/linux/hid.h:1039 [<ffffffc0012cc7a0>] hidraw_send_report+0x400/0x414 drivers/hid/hidraw.c:154 [<ffffffc0012cc7f4>] hidraw_write+0x40/0x64 drivers/hid/hidraw.c:177 [<ffffffc0004681dc>] vfs_write+0x1d4/0x3cc fs/read_write.c:534 [< inline >] SYSC_pwrite64 fs/read_write.c:627 [<ffffffc000468984>] SyS_pwrite64+0xec/0x144 fs/read_write.c:614 Object at ffffffc07135ea80, in cache kmalloc-512 Object allocated with size 268 bytes. Let's check data length against the buffer size before attempting to copy data over. Cc: stable@vger.kernel.org Reported-by: Alexander Potapenko <glider@google.com> Signed-off-by: Dmitry Torokhov <dtor@chromium.org> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: multitouch: fix input mode switching on some Elan panelsBenjamin Tissoires2016-04-121-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 73e7d63efb4d774883a338997943bfa59e127085 ] as reported by https://bugzilla.kernel.org/show_bug.cgi?id=108481 This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature reports on demand for Win8 devices") as the origin of the problem but this commit actually masked 2 firmware bugs that are annihilating each other: The report descriptor declares two features in reports 3 and 5: 0x05, 0x0d, // Usage Page (Digitizers) 318 0x09, 0x0e, // Usage (Device Configuration) 320 0xa1, 0x01, // Collection (Application) 322 0x85, 0x03, // Report ID (3) 324 0x09, 0x22, // Usage (Finger) 326 0xa1, 0x00, // Collection (Physical) 328 0x09, 0x52, // Usage (Inputmode) 330 0x15, 0x00, // Logical Minimum (0) 332 0x25, 0x0a, // Logical Maximum (10) 334 0x75, 0x08, // Report Size (8) 336 0x95, 0x02, // Report Count (2) 338 0xb1, 0x02, // Feature (Data,Var,Abs) 340 0xc0, // End Collection 342 0x09, 0x22, // Usage (Finger) 343 0xa1, 0x00, // Collection (Physical) 345 0x85, 0x05, // Report ID (5) 347 0x09, 0x57, // Usage (Surface Switch) 349 0x09, 0x58, // Usage (Button Switch) 351 0x15, 0x00, // Logical Minimum (0) 353 0x75, 0x01, // Report Size (1) 355 0x95, 0x02, // Report Count (2) 357 0x25, 0x03, // Logical Maximum (3) 359 0xb1, 0x02, // Feature (Data,Var,Abs) 361 0x95, 0x0e, // Report Count (14) 363 0xb1, 0x03, // Feature (Cnst,Var,Abs) 365 0xc0, // End Collection 367 The report ID 3 presents 2 input mode features, while only the first one is handled by the device. Given that we did not checked if one was previously assigned, we were dealing with the ignored featured and we should never have been able to switch this panel into the multitouch mode. However, the firmware presents an other bugs which allowed 6d4f5440 to counteract the faulty report descriptor. When we request the values of the feature 5, the firmware answers "03 03 00". The fields are correct but the report id is wrong. Before 6d4f5440, we retrieved all the features and injected them in the system. So when we called report 5, we injected in the system the report 3 with the values "03 00". Setting the second input mode to 03 in this report changed it to "03 03" and the touchpad switched to the mt mode. We could have set anything in the second field because the actual value (the first 03 in this report) was given by the query of report ID 5. To sum up: 2 bugs in the firmware were hiding that we were accessing the wrong feature. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: fix hid_ignore_special_drivers module parameterBenjamin Tissoires2016-04-121-3/+4
| | | | | | | | | | | | | | | | | | | [ Upstream commit 4392bf333388cabdad5afe5b1500002d7b9c318e ] hid_ignore_special_drivers works fine until hid_scan_report autodetects and reassign devices (for hid-multitouch, hid-microsoft and hid-rmi). Simplify the handling of the parameter: if it is there, use hid-generic, no matter what, and if not, scan the device or rely on the hid_have_special_driver table. This was detected while trying to disable hid-multitouch on a Surface Pro cover which prevented to use the keyboard. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> CC: stable@vger.kernel.org Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: core: do not scan reports if the group is already setBenjamin Tissoires2016-04-121-1/+2
| | | | | | | | | | | | | [ Upstream commit 9578f41aeaee5010384f4f8484da1566e2ce4901 ] This allows the transport layer (I have in mind hid-logitech-dj and uhid) to set the group before it is added to the hid bus. This way, it can bypass the hid_scan_report() call, and choose in advance which driver will handle the newly created hid device. Signed-off-by: Benjamin Tisssoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: usbhid: fix recursive deadlockIoan-Adrian Ratiu2016-03-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e470127e9606b1fa151c4184243e61296d1e0c0f upstream. The critical section protected by usbhid->lock in hid_ctrl() is too big and because of this it causes a recursive deadlock. "Too big" means the case statement and the call to hid_input_report() do not need to be protected by the spinlock (no URB operations are done inside them). The deadlock happens because in certain rare cases drivers try to grab the lock while handling the ctrl irq which grabs the lock before them as described above. For example newer wacom tablets like 056a:033c try to reschedule proximity reads from wacom_intuos_schedule_prox_event() calling hid_hw_request() -> usbhid_request() -> usbhid_submit_report() which tries to grab the usbhid lock already held by hid_ctrl(). There are two ways to get out of this deadlock: 1. Make the drivers work "around" the ctrl critical region, in the wacom case for ex. by delaying the scheduling of the proximity read request itself to a workqueue. 2. Shrink the critical region so the usbhid lock protects only the instructions which modify usbhid state, calling hid_input_report() with the spinlock unlocked, allowing the device driver to grab the lock first, finish and then grab the lock afterwards in hid_ctrl(). This patch implements the 2nd solution. Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: quirks: add QUIRK_NOGET for an other TPV touchscreenBenjamin Tissoires2015-12-022-2/+4
| | | | | | | | | | | | | [ Upstream commit c9b57724b38d4c1555ee49418be3d76801e3327c ] Looks like 0x8882 needs the same quirk than 0x8883. Given that both devices claim they are "TPV OpticalTouchScreen" rename the 0x8883 to add its PID in the #define. Reported-by: Blaine Lee <blaine.j.lee@medtronic.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: apple: Add support for the 2015 Macbook ProHenrik Rydberg2015-12-023-0/+15
| | | | | | | | | | | | | | | | | | | [ Upstream commit a4a2c54560f2c57b88ba0283f141b44f594c2337 ] This patch adds keyboard support for MacbookPro12,1 as WELLSPRING9 (0x0272, 0x0273, 0x0274). The touchpad is handled in a separate bcm5974 patch, as usual. Tested-by: John Horan <knasher@gmail.com> Tested-by: Jochen Radmacher <jradmacher@gmx.de> Tested-by: Yang Hongyang <burnef@gmail.com> Tested-by: Yen-Chin, Lee <coldnew.tw@gmail.com> Tested-by: George Hilios <ghilios@gmail.com> Tested-by: Janez Urevc <janez@janezurevc.name> Signed-off-by: Henrik Rydberg <rydberg@bitmath.org> Acked-by: Jiri Kosina <jkosina@suse.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: usbhid: Fix the check for HID_RESET_PENDING in hid_io_errorDon Zickus2015-10-271-1/+1
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit 3af4e5a95184d6d3c1c6a065f163faa174a96a1d ] It was reported that after 10-20 reboots, a usb keyboard plugged into a docking station would not work unless it was replugged in. Using usbmon, it turns out the interrupt URBs were streaming with callback errors of -71 for some reason. The hid-core.c::hid_io_error was supposed to retry and then reset, but the reset wasn't really happening. The check for HID_NO_BANDWIDTH was inverted. Fix was simple. Tested by reporter and locally by me by unplugging a keyboard halfway until I could recreate a stream of errors but no disconnect. Signed-off-by: Don Zickus <dzickus@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: usbhid: add Chicony/Pixart usb optical mouse that needs QUIRK_ALWAYS_POLLHerton R. Krzesinski2015-09-272-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 7250dc3fee806eb2b7560ab7d6072302e7ae8cf8 ] I received a report from an user of following mouse which needs this quirk: usb 1-1.6: USB disconnect, device number 58 usb 1-1.6: new low speed USB device number 59 using ehci_hcd usb 1-1.6: New USB device found, idVendor=04f2, idProduct=1053 usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.6: Product: USB Optical Mouse usb 1-1.6: Manufacturer: PixArt usb 1-1.6: configuration #1 chosen from 1 choice input: PixArt USB Optical Mouse as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input5887 generic-usb 0003:04F2:1053.16FE: input,hidraw2: USB HID v1.11 Mouse [PixArt USB Optical Mouse] on usb-0000:00:1a.0-1.6/input0 The quirk was tested by the reporter and it fixed the frequent disconnections etc. [jkosina@suse.cz: reorder the position in hid-ids.h] Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: do not bind to Microchip Pick16F1454Kristian Evensen2015-08-272-0/+2
| | | | | | | | | | | | | [ Upstream commit a8c8316b11594e616df641b4b19ec9da732f93df ] The Microchip Pick16F1454 is exported as a HID device and is used by for example the Yepkit YKUSH three-port switchable USB hub. However, it is not an actual HID-device. On the Yepkit, it is used to power up/down the ports on the hub. The HID driver should ignore this device. Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* [media] si4713: HID blacklist Si4713 USB development boardDinesh Ram2015-08-271-0/+2
| | | | | | | | | | | | | | | | | | | [ Upstream commit adc232592337d3ac4c5473ba8bdaf7c202bf215d ] The Si4713 development board contains a Si4713 FM transmitter chip and is handled by the radio-usb-si4713 driver. The board reports itself as (10c4:8244) Cygnal Integrated Products, Inc. and misidentifies itself as a HID device in its USB interface descriptor. This patch ignores this device as an HID device and hence loads the custom driver. Signed-off-by: Dinesh Ram <dinesh.ram@cern.ch> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Eduardo Valentin <edubezval@gmail.com> Acked-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: tivo: enable all buttons on the TiVo Slide Pro remoteForest Wilkinson2015-08-273-0/+3
| | | | | | | | | | | | | | [ Upstream commit 9b028649b9d0ae72090904629dad06b022f4ddc7 ] The linux kernel has supported the TiVo Slide remote control for some time, but does not recognize the USB ID of the newer Slide Pro. This patch adds the missing data structures so the newer remote will be recognized by the driver, thereby allowing the TiVo, LiveTV, and Thumbs Up/Down buttons to be mapped with a hwdb file. Signed-off-by: Forest Wilkinson <web11.forest@tibit.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: sony: Add support for the third-party SMK PS3 Bluetooth RemoteFrank Praznik2015-06-283-0/+7
| | | | | | | | | | | [ Upstream commit 68a49e51a4a9c500d950f893f1758c5ac13b7c8b ] Add vid/pid for the SMK branded third-party PS3 Bluetooth remote and enable support in the hid-sony driver. Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: usbhid: Add HID_QUIRK_NOGET for Aten DVI KVM switchLaura Abbott2015-06-282-0/+2
| | | | | | | | | | | | | | | | | [ Upstream commit 849eca7b9dae0364e2fbe8afdf0fb610d12c9c8f ] Like other KVM switches, the Aten DVI KVM switch needs a quirk to avoid spewing errors: [791759.606542] usb 1-5.4: input irq status -75 received [791759.614537] usb 1-5.4: input irq status -75 received [791759.622542] usb 1-5.4: input irq status -75 received Add it. Signed-off-by: Laura Abbott <labbott@fedoraproject.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: sjoy: support Super Joy Box 4Sean Young2015-06-283-1/+4
| | | | | | | | | | [ Upstream commit 6e5e9a06a206010eabd19b523fd0833c51afc0b0 ] This device supports force feedback and has two ports. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: usbhid: Add a quirk for raphnet multi-gamepad adaptersRaphael Assenat2015-06-282-0/+10
| | | | | | | | | | | | | | | | [ Upstream commit d6ea2f88ac3659b799d8079a4fbda4f8faf6ff90 ] The raphnet.net 4nes4snes and 2nes2snes multi-joystick adapters use a single HID report descriptor with one report ID per controller. This has the effect that the inputs of otherwise independent game controllers get packed in one large joystick device. With this patch each controller gets its own /dev/input/jsX device, which is more natural and less confusing than having all inputs going to the same place. Signed-off-by: Raphael Assenat <raph@raphnet.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: usbhid: yet another mouse with ALWAYS_POLLOliver Neukum2015-06-282-2/+4
| | | | | | | | | | | [ Upstream commit 43faadfe96d3f049f4ae2c4090d2e57b9aafb995 ] The device exists with two device IDs instead of one as previously believed. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: usbhid: more mice with ALWAYS_POLLOliver Neukum2015-06-282-0/+8
| | | | | | | | | | | [ Upstream commit 003e817a9ecf6cfded59630858bbf04056d71e9a ] During a stress test these mice kept dropping and reappearing in runlevel 1 as opposed to 5. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: add quirk for PIXART OEM mouse used by HPOliver Neukum2015-06-282-0/+2
| | | | | | | | | | | | [ Upstream commit b70b82580248b5393241c986082842ec05a2b7d7 ] This mouse is also known under other IDs. It needs the quirk or will disconnect in runlevel 1 or 3. Signed-off-by: Oliver Neukum <oneukum@suse.de> CC: stable@vger.kernel.org Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: add HP OEM mouse to quirk ALWAYS_POLLOliver Neukum2015-06-282-0/+4
| | | | | | | | | | | [ Upstream commit 7a8e53c414c8183e8735e3b08d9a776200e6e665 ] This mouse needs QUIRK_ALWAYS_POLL. Signed-off-by: Oliver Neukum <oneukum@suse.de> CC: stable@vger.kernel.org Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: add ALWAYS_POLL quirk for a Logitech 0xc007oliver@neukum.org2015-06-282-0/+2
| | | | | | | | | | [ Upstream commit a415457733b5fa40bc996bf1f4df471cd98d3608 ] This device disconnects every 60s without X Signed-off-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: Introduce hidpp, a module to handle Logitech hid++ devicesBenjamin Tissoires2015-06-285-0/+856
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 2f31c52529103d8f0e1485272064f982d14ce54a ] Logitech devices use a vendor protocol to communicate various information with the device. This protocol is called HID++, and an exerpt can be found here: https://drive.google.com/folderview?id=0BxbRzx7vEV7eWmgwazJ3NUFfQ28&usp=shar The main difficulty which is related to this protocol is that it is a synchronous protocol using the input reports. So when we want to get some information from the device, we need to wait for a matching input report. This driver introduce this capabilities to be able to support the multitouch mode of the Logitech Wireless Touchpad T651 (the bluetooth one). The multitouch data is available directly from the mouse input reports, and we just need to query the device on connect about its caracteristics. HID++ and the touchpad features has a specific reporting mode which uses pure HID++ reports, but Logitech told us not to use it for this specific device. During QA, they detected that some bluetooth input reports where lost, and so the only supported mode is the pointer mode. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: microsoft: Add ID for NE7K wireless keyboardJakub Sitnicki2015-06-283-0/+4
| | | | | | | | | | | | | | | | | [ Upstream commit ef567cf9ddb682dbfa840bf4a2600931299f9555 ] Microsoft Natural Wireless Ergonomic Keyboard 7000 has special My Favorites 1..5 keys which are handled through a vendor-defined usage page (0xff05). Apply MS_ERGONOMY quirks handling to USB PID 0x071d (Microsoft Microsoft 2.4GHz Transceiver V1.0) so that the My Favorites 1..5 keys are reported as KEY_F14..18 events. Link: https://bugzilla.kernel.org/show_bug.cgi?id=52841 Signed-off-by: Jakub Sitnicki <jsitnicki@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: saitek: add USB ID for older R.A.T. 7Darren Salt2015-06-283-0/+4
| | | | | | | | [ Upstream commit afe98939b37933ee8c3d0b5c42199d624d0408a6 ] Signed-off-by: Darren Salt <devspam@moreofthesa.me.uk> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: uclogic: Set quirks from inside the driverBenjamin Tissoires2015-06-282-4/+27
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 70b69cfb88467988116c4863056495fa3615271a ] Based on a patch from: Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com> Most of the tablets handled by hid-uclogic already use MULTI_INPUT. For the ones which are not quirked in usbhid/hidquirks, they have a custom report descriptor which contains only one report per HID interface. For those tablets HID_QUIRK_MULTI_INPUT is transparent. According to https://github.com/DIGImend/tablets, the only problematic tablet currently handled by hid-uclogic is the TWHA60 v3. This tablet presents different report descriptors from the ones currently quirked. This is not a problem per se, given that this tablet is not supported currently in this version (it needs the same command as a Huion to start forwarding events). Reviewed-by: Nikolai Kondrashov <spbnick@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: kye: Fix report descriptor for Genius PenSketch M912Milan Plzik2015-06-284-0/+143
| | | | | | | | | | | | [ Upstream commit feb6faf1e5d46276c5430e36ffb4a6f62bf8d55b ] Genius PenSketch M912 digitizer tablet sends incorrect report descriptor by default. This patch replaces it with a corrected one. Signed-off-by: Milan Plzik <milan.plzik@gmail.com> Reviewed-by: Nikolai Kondrashov <spbnick@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
* HID: wacom: Report ABS_MISC event for Cintiq Companion HybridJason Gerecke2015-03-231-0/+6
| | | | | | | | | | | | | | | | | | | | commit 33e5df0e0e32027866e9fb00451952998fc957f2 upstream. It appears that the Cintiq Companion Hybrid does not send an ABS_MISC event to userspace when any of its ExpressKeys are pressed. This is not strictly necessary now that the pad exists on its own device, but should be fixed for consistency's sake. Traditionally both the stylus and pad shared the same device node, and xf86-input-wacom would use ABS_MISC for disambiguation. Not sending this causes the Hybrid to behave incorrectly with xf86-input-wacom beginning with its 8f44f3 commit. Signed-off-by: Jason Gerecke <killertofu@gmail.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: fixup the conflicting keyboard mappings quirkJiri Kosina2015-03-231-0/+1
| | | | | | | | | | | | | | | | commit 8e7b341037db1835ee6eea64663013cbfcf33575 upstream. 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. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: input: fix confusion on conflicting mappingsDavid Herrmann2015-03-231-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 6ce901eb61aa30ba8565c62049ee80c90728ef14 upstream. 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. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: i2c-hid: Limit reads to wMaxInputLength bytes for input eventsSeth Forshee2015-03-061-1/+4
| | | | | | | | | | | | | | | | | | | commit 6d00f37e49d95e640a3937a4a1ae07dbe92a10cb upstream. d1c7e29e8d27 (HID: i2c-hid: prevent buffer overflow in early IRQ) changed hid_get_input() to read ihid->bufsize bytes, which can be more than wMaxInputLength. This is the case with the Dell XPS 13 9343, and it is causing events to be missed. In some cases the missed events are releases, which can cause the cursor to jump or freeze, among other problems. Limit the number of bytes read to min(wMaxInputLength, ihid->bufsize) to prevent such problems. Fixes: d1c7e29e8d27 "HID: i2c-hid: prevent buffer overflow in early IRQ" Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: rmi: Check for additional ACM registers appended to F11 data reportAndrew Duggan2015-02-051-9/+52
| | | | | | | | | | | | | | | | | | | commit 8414947a2018a98cf3adc975dc279f41ba30ab11 upstream. If a touchpad reports the F11 data40 register then this indicates that the touchpad reports additional ACM (Accidental Contact Mitigation) data after the F11 data in the HID attention report. These additional bytes shift the position of the F30 button data causing the driver to incorrectly report button state when this functionality is present. This patch accounts for the additional data in the report. Fixes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1398533 Signed-off-by: Andrew Duggan <aduggan@synaptics.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Cc: Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: Add a new id 0x501a for Genius MousePen i608XGiedrius Statkevičius2015-01-164-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | commit 2bacedada682d5485424f5227f27a3d5d6eb551c upstream. New Genius MousePen i608X devices have a new id 0x501a instead of the old 0x5011 so add a new #define with "_2" appended and change required places. The remaining two checkpatch warnings about line length being over 80 characters are present in the original files too and this patch was made in the same style (no line break). Just adding a new id and changing the required places should make the new device work without any issues according to the bug report in the following url. This patch was made according to and fixes: https://bugzilla.kernel.org/show_bug.cgi?id=67111 Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: add battery quirk for USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO keyboardKarl Relton2015-01-161-0/+3
| | | | | | | | | | | | | | commit da940db41dcf8c04166f711646df2f35376010aa upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* HID: i2c-hid: Do not free buffers in i2c_hid_stop()Mika Westerberg2015-01-161-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 5b44c53aeb791757072be4a267255cedfff594fd upstream. When a hid driver that uses i2c-hid as transport is unloaded, the hid core will call i2c_hid_stop() which releases all the buffers associated with the device. This includes also the command buffer. Now, when the i2c-hid driver itself is unloaded it tries to power down the device by sending it PWR_SLEEP command. Since the command buffer is already released we get following crash: [ 79.691459] BUG: unable to handle kernel NULL pointer dereference at (null) [ 79.691532] IP: [<ffffffffa05bc049>] __i2c_hid_command+0x49/0x310 [i2c_hid] ... [ 79.693467] Call Trace: [ 79.693494] [<ffffffff810424e1>] ? __unmask_ioapic+0x21/0x30 [ 79.693537] [<ffffffff81042855>] ? unmask_ioapic+0x25/0x40 [ 79.693581] [<ffffffffa05bc35b>] ? i2c_hid_set_power+0x4b/0xa0 [i2c_hid] [ 79.693632] [<ffffffffa05bc3cf>] ? i2c_hid_runtime_resume+0x1f/0x30 [i2c_hid] [ 79.693689] [<ffffffff814c08fb>] ? __rpm_callback+0x2b/0x70 [ 79.693733] [<ffffffff814c0961>] ? rpm_callback+0x21/0x90 [ 79.693776] [<ffffffff814c0dec>] ? rpm_resume+0x41c/0x600 [ 79.693820] [<ffffffff814c1e1c>] ? __pm_runtime_resume+0x4c/0x80 [ 79.693868] [<ffffffff814b8588>] ? __device_release_driver+0x28/0x100 [ 79.693917] [<ffffffff814b8d90>] ? driver_detach+0xa0/0xb0 [ 79.693959] [<ffffffff814b82cc>] ? bus_remove_driver+0x4c/0xb0 [ 79.694006] [<ffffffff810d1cfd>] ? SyS_delete_module+0x11d/0x1d0 [ 79.694054] [<ffffffff8165f107>] ? int_signal+0x12/0x17 [ 79.694095] [<ffffffff8165ee69>] ? system_call_fastpath+0x12/0x17 Fix this so that we only free buffers when the i2c-hid driver itself is removed. Fixes: 34f439e4afcd ("HID: i2c-hid: add runtime PM support") Reported-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.46.0) at 2025-04-24 02:51:36 +0000