1. 30 May, 2019 1 commit
  2. 26 Apr, 2019 1 commit
  3. 24 Apr, 2019 2 commits
  4. 03 Apr, 2019 1 commit
  5. 27 Mar, 2019 5 commits
  6. 13 Feb, 2019 1 commit
  7. 07 Dec, 2018 1 commit
    • Peter Hutterer's avatar
      HID: input: use the Resolution Multiplier for high-resolution scrolling · 2dc702c9
      Peter Hutterer authored
      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
      Note that all mice encountered so far have a logical min/max of 0/1, so
      it's a binary "yes or no" to high-res scrolling anyway.
      To make userspace simpler, always enable the REL_WHEEL_HI_RES bit. Where
      the device doesn't support high-resolution scrolling, the value for the
      high-res data will simply be a multiple of 120 every time. For userspace,
      if REL_WHEEL_HI_RES is available that is the one to be used.
      Potential side-effect: a device with a Resolution Multiplier applying to
      other Input items will have those items set to the logical max as well.
      This cannot easily be worked around but it is doubtful such devices exist.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <[email protected]>
      Verified-by: default avatarHarry Cutts <[email protected]>
      Signed-off-by: default avatarBenjamin Tissoires <[email protected]>
  8. 22 Nov, 2018 2 commits
  9. 12 Nov, 2018 1 commit
  10. 29 Oct, 2018 1 commit
    • Linus Torvalds's avatar
      HID: input: simplify/fix high-res scroll event handling · 044ee890
      Linus Torvalds authored
      Commit 1ff2e1a4 ("HID: input: Create a utility class for counting
      scroll events") created the helper function
      to handle high-res scroll events and also expose them as regular wheel
      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 <[email protected]>
      Cc: Harry Cutts <[email protected]>
      Cc: Benjamin Tissoires <[email protected]>
      Cc: Peter Hutterer <[email protected]>
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
  11. 05 Sep, 2018 2 commits
  12. 04 Sep, 2018 2 commits
  13. 28 Aug, 2018 1 commit
  14. 17 Jul, 2018 1 commit
    • Benjamin Tissoires's avatar
      HID: input: enable Totem on the Dell Canvas 27 · ba6b055e
      Benjamin Tissoires authored
      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
      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
      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=1511846Acked-by: Peter Hutterer's avatarPeter Hutterer <[email protected]>
      Signed-off-by: default avatarBenjamin Tissoires <[email protected]>
      Signed-off-by: default avatarJiri Kosina <[email protected]>
  15. 26 Apr, 2018 3 commits
  16. 17 Apr, 2018 1 commit
    • Benjamin Tissoires's avatar
      HID: input: do not increment usages when a duplicate is found · 190d7f02
      Benjamin Tissoires authored
      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
      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: default avatarBenjamin Tissoires <[email protected]>
      Acked-by: Peter Hutterer's avatarPeter Hutterer <[email protected]>
      Acked-by: default avatarDmitry Torokhov <[email protected]>
      Signed-off-by: default avatarJiri Kosina <[email protected]>
  17. 09 Apr, 2018 1 commit
    • Dmitry Torokhov's avatar
      HID: input: fix battery level reporting on BT mice · 2e210bbb
      Dmitry Torokhov authored
      The commit 581c4484 ("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
      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: 581c4484 ("HID: input: map digitizer battery usage")
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198095
      Cc: [email protected]
      Reported-and-tested-by: default avatarMartin van Es <[email protected]>
      Signed-off-by: default avatarDmitry Torokhov <[email protected]>
      Signed-off-by: default avatarJiri Kosina <[email protected]>
  18. 23 Mar, 2018 1 commit
  19. 16 Feb, 2018 1 commit
  20. 05 Oct, 2017 1 commit
  21. 15 Aug, 2017 1 commit
  22. 02 Aug, 2017 2 commits
  23. 22 May, 2017 1 commit
  24. 11 May, 2017 1 commit
  25. 21 Mar, 2017 1 commit
    • Tomasz Kramkowski's avatar
      HID: clamp input to logical range if no null state · c3883fe0
      Tomasz Kramkowski authored
      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 3f375270 ("HID: reject input outside
      logical range only if null state is set").
      [1]: http://lkml.kernel.org/r/[email protected]
      [2]: https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85).aspSigned-off-by: Tomasz Kramkowski's avatarTomasz Kramkowski <[email protected]>
      Acked-by: default avatarBenjamin Tissoires <[email protected]>
      Signed-off-by: default avatarJiri Kosina <[email protected]>
  26. 06 Mar, 2017 1 commit
  27. 28 Nov, 2016 1 commit
    • Benjamin Tissoires's avatar
      HID: input: rework HID_QUIRK_MULTI_INPUT · 72d19459
      Benjamin Tissoires authored
      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
      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: default avatarBenjamin Tissoires <[email protected]>
      Signed-off-by: default avatarJiri Kosina <[email protected]>
  28. 20 Oct, 2016 1 commit
    • Jason Gerecke's avatar
      HID: input: Recognize ABS_WHEEL in hidinput_calc_abs_res · c0bf5741
      Jason Gerecke authored
      The "Steering" usage (HID_UP_SIMULATION | 0xc8) is defined in HUT 1.12 as
      "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: default avatarJason Gerecke <[email protected]>
      Reviewed-by: default avatarBenjamin Tissoires <[email protected]>
      Signed-off-by: default avatarJiri Kosina <[email protected]>
  29. 19 Sep, 2016 1 commit