Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 09 12月, 2021 1 次提交
  3. 19 11月, 2021 3 次提交
  5. 15 9月, 2021 1 次提交
  7. 16 7月, 2021 1 次提交
  9. 24 6月, 2021 1 次提交
  11. 14 6月, 2021 1 次提交
  13. 05 5月, 2021 2 次提交
  15. 07 4月, 2021 1 次提交
  17. 09 2月, 2021 1 次提交
  19. 02 2月, 2021 1 次提交
    • D
      HID: hid-input: avoid splitting keyboard, system and consumer controls · 7c7d7ac7
      由 Dmitry Torokhov 提交于 
      A typical USB keyboard usually splits its keys into several reports:

- one for the basic alphanumeric keys, modifier keys, F<n> keys, six pack
  keys and keypad. This report's application is normally listed as
  GenericDesktop.Keyboard
- a GenericDesktop.SystemControl report for the system control keys, such
  as power and sleep
- Consumer.ConsumerControl report for multimedia (forward, rewind,
  play/pause, mute, etc) and other extended keys.
- additional output, vendor specific, and feature reports

Splitting each report into a separate input device is wasteful and even
hurts userspace as it makes it harder to determine the true capabilities
(set of available keys) of a keyboard, so let's adjust application
matching to merge system control and consumer control reports with
keyboard report, if one has already been processed.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NPeter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      7c7d7ac7
  21. 08 1月, 2021 1 次提交
  23. 25 11月, 2020 1 次提交
  25. 12 11月, 2020 1 次提交
  27. 29 10月, 2020 1 次提交
  29. 26 9月, 2020 1 次提交
  31. 01 9月, 2020 1 次提交
    • M
      HID: core: Sanitize event code and type when mapping input · 35556bed
      由 Marc Zyngier 提交于 
      When calling into hid_map_usage(), the passed event code is
blindly stored as is, even if it doesn't fit in the associated bitmap.

This event code can come from a variety of sources, including devices
masquerading as input devices, only a bit more "programmable".

Instead of taking the event code at face value, check that it actually
fits the corresponding bitmap, and if it doesn't:
- spit out a warning so that we know which device is acting up
- NULLify the bitmap pointer so that we catch unexpected uses

Code paths that can make use of untrusted inputs can now check
that the mapping was indeed correct and bail out if not.

Cc: stable@vger.kernel.org
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
      35556bed
  33. 14 7月, 2020 1 次提交
    • G
      HID: input: Fix devices that return multiple bytes in battery report · 4f57cace
      由 Grant Likely 提交于 
      Some devices, particularly the 3DConnexion Spacemouse wireless 3D
controllers, return more than just the battery capacity in the battery
report. The Spacemouse devices return an additional byte with a device
specific field. However, hidinput_query_battery_capacity() only
requests a 2 byte transfer.

When a spacemouse is connected via USB (direct wire, no wireless dongle)
and it returns a 3 byte report instead of the assumed 2 byte battery
report the larger transfer confuses and frightens the USB subsystem
which chooses to ignore the transfer. Then after 2 seconds assume the
device has stopped responding and reset it. This can be reproduced
easily by using a wired connection with a wireless spacemouse. The
Spacemouse will enter a loop of resetting every 2 seconds which can be
observed in dmesg.

This patch solves the problem by increasing the transfer request to 4
bytes instead of 2. The fix isn't particularly elegant, but it is simple
and safe to backport to stable kernels. A further patch will follow to
more elegantly handle battery reports that contain additional data.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Cc: Darren Hart <darren@dvhart.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: stable@vger.kernel.org
Tested-by: NDarren Hart <dvhart@infradead.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      4f57cace
  35. 16 6月, 2020 1 次提交
    • P
      HID: input: do not run GET_REPORT unless there's a Resolution Multiplier · 1ad273d6
      由 Peter Hutterer 提交于 
      hid-multitouch currently runs GET_REPORT for Contact Max and again to
retrieve the Win8 blob. If both are within the same report, the
Resolution Multiplier code calls GET_FEATURE again and this time,
possibly due to timing, it causes the ILITEK-TP device interpret the
GET_FEATURE as an instruction to change the mode and effectively stop
the device from functioning as expected.

Notably: the device doesn't even have a Resolution Multiplier so it
shouldn't be affected by any of this at all.

Fix this by making sure we only execute GET_REPORT if there is
a Resolution Multiplier in the respective report. Where the
HID_QUIRK_NO_INIT_REPORTS field is set we just bail out immediately. This
shouldn't be triggered by any real device anyway.
Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
Tested-by: NWen He <wen.he_1@nxp.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      1ad273d6
  37. 13 12月, 2019 1 次提交
    • D
      HID: hid-input: clear unmapped usages · 4f388217
      由 Dmitry Torokhov 提交于 
      We should not be leaving half-mapped usages with potentially invalid
keycodes, as that may confuse hidinput_find_key() when the key is located
by index, which may end up feeding way too large keycode into the VT
keyboard handler and cause OOB write there:

BUG: KASAN: global-out-of-bounds in clear_bit include/asm-generic/bitops-instrumented.h:56 [inline]
BUG: KASAN: global-out-of-bounds in kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
BUG: KASAN: global-out-of-bounds in kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
Write of size 8 at addr ffffffff89a1b2d8 by task syz-executor108/1722
...
 kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
 kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
 input_to_handler+0x3b6/0x4c0 drivers/input/input.c:118
 input_pass_values.part.0+0x2e3/0x720 drivers/input/input.c:145
 input_pass_values drivers/input/input.c:949 [inline]
 input_set_keycode+0x290/0x320 drivers/input/input.c:954
 evdev_handle_set_keycode_v2+0xc4/0x120 drivers/input/evdev.c:882
 evdev_do_ioctl drivers/input/evdev.c:1150 [inline]

Cc: stable@vger.kernel.org
Reported-by: syzbot+19340dff067c2d3835c0@syzkaller.appspotmail.com
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      4f388217
  39. 31 5月, 2019 1 次提交
  41. 27 4月, 2019 1 次提交
  43. 24 4月, 2019 2 次提交
  45. 03 4月, 2019 1 次提交
  47. 27 3月, 2019 5 次提交
  49. 14 2月, 2019 1 次提交
  51. 07 12月, 2018 1 次提交
    • P
      HID: input: use the Resolution Multiplier for high-resolution scrolling · 2dc702c9
      由 Peter Hutterer 提交于 
      Windows uses a magic number of 120 for a wheel click. High-resolution
scroll wheels are supposed to use a fraction of 120 to signal smaller
scroll steps. This is implemented by the Resolution Multiplier in the
device itself.

If the multiplier is present in the report descriptor, set it to the
logical max and then use the resolution multiplier to calculate the
high-resolution events. This is the recommendation by Microsoft, see
http://msdn.microsoft.com/en-us/windows/hardware/gg487477.aspx

Note that all mice encountered so far have a logical min/max of 0/1, so
it's a binary "yes or no" to high-res scrolling anyway.

To make userspace simpler, always enable the REL_WHEEL_HI_RES bit. Where
the device doesn't support high-resolution scrolling, the value for the
high-res data will simply be a multiple of 120 every time. For userspace,
if REL_WHEEL_HI_RES is available that is the one to be used.

Potential side-effect: a device with a Resolution Multiplier applying to
other Input items will have those items set to the logical max as well.
This cannot easily be worked around but it is doubtful such devices exist.
Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
Verified-by: NHarry Cutts <hcutts@chromium.org>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      2dc702c9
  53. 22 11月, 2018 2 次提交
  55. 12 11月, 2018 1 次提交
  57. 30 10月, 2018 1 次提交
    • L
      HID: input: simplify/fix high-res scroll event handling · 044ee890
      由 Linus Torvalds 提交于 
      Commit 1ff2e1a4 ("HID: input: Create a utility class for counting
scroll events") created the helper function

    hid_scroll_counter_handle_scroll()

to handle high-res scroll events and also expose them as regular wheel
events.

But the resulting algorithm was unstable, and causes scrolling to be
very unreliable.  When you hit the half-way mark of the highres
multiplier, small highres movements will incorrectly translate into big
traditional wheel movements, causing odd jitters.

Simplify the code and make the output stable.

NOTE! I'm pretty sure this will need further tweaking.  But this at
least turns a unusable mouse wheel on my Logitech MX Anywhere 2S into
a usable one.

Cc: Jiri Kosina <jikos@kernel.org>
Cc: Harry Cutts <hcutts@chromium.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      044ee890
  59. 05 9月, 2018 2 次提交