1. 24 4月, 2019 1 次提交
  2. 18 3月, 2019 1 次提交
  3. 16 1月, 2019 1 次提交
  4. 10 1月, 2019 1 次提交
  5. 07 12月, 2018 2 次提交
    • P
      HID: core: process the Resolution Multiplier · 5a4abb36
      Peter Hutterer 提交于
      The Resolution Multiplier is a feature report that modifies the value of
      Usages within the same Logical Collection. If the multiplier is set to
      anything but 1, the hardware reports (value * multiplier) for the same amount
      of physical movement, i.e. the value we receive in the kernel is
      pre-multiplied.
      
      The hardware may either send a single (value * multiplier), or by sending
      multiplier as many reports with the same value, or a combination of these two
      options. For example, when the Microsoft Sculpt Ergonomic mouse Resolution
      Multiplier is set to 12, the Wheel sends out 12 for every detent but AC Pan
      sends out a value of 3 at 4 times the frequency.
      
      The effective multiplier is based on the physical min/max of the multiplier
      field, a logical min/max of [0,1] with a physical min/max of [1,8] means the
      multiplier is either 1 or 8.
      
      The Resolution Multiplier was introduced for high-resolution scrolling in
      Windows Vista and is commonly used on Microsoft mice.
      
      The recommendation for the Resolution Multiplier is to default to 1 for
      backwards compatibility. This patch adds an arbitrary upper limit at 255. The
      only known use case for the Resolution Multiplier is for scroll wheels where the
      multiplier has to be a fraction of 120 to work with Windows.
      Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
      Verified-by: NHarry Cutts <hcutts@chromium.org>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      5a4abb36
    • P
      HID: core: store the collections as a basic tree · c53431eb
      Peter Hutterer 提交于
      For each collection parsed, store a pointer to the parent collection
      (if any). This makes it a lot easier to look up which collection(s)
      any given item is part of
      Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
      Verified-by: NHarry Cutts <hcutts@chromium.org>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      c53431eb
  6. 05 9月, 2018 1 次提交
  7. 28 8月, 2018 2 次提交
    • S
      HID: core: fix memory leak on probe · b2dd9f2e
      Stefan Agner 提交于
      The dynamically allocted collection stack does not get freed in
      all situations. Make sure to also free the collection stack when
      using the parser in hid_open_report().
      
      Fixes: 08a8a7cf ("HID: core: do not upper bound the collection stack")
      Signed-off-by: NStefan Agner <stefan@agner.ch>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      b2dd9f2e
    • S
      HID: increase maximum global item tag report size to 256 · 71f6fa90
      Song, Hongyan 提交于
      The maximum globale report size has changed from 32->...->96->128 in the past
      years.  With the development usage of HID, the report_size max value 128 cannot
      satisfy all requirements.
      
      There are applications need to expose intrinsic metadata to camera stabilizing
      applications such as 3DFE application. 3DFE intrinsic is designed to express
      environmental information about sensor that may dynamically change while the
      sensor is running (such data include noise spectral density, bias standard
      deviation)
      
      A sensor data field is SENSOR_VALUE_PAIR that consists of a PROPERTYKEY and
      PROPVARIANT pair. It need to report a unique PROPERTYKEY for each data field.
      
      Take “Noise Spectral Density” as an example, it report count will be
      defined as below:
      
      	"Size of Property key GUID(16 Byte) + property key index(4 Byte) +
      	size of Noise Spectral Density value(4 Byte)"
      
      In this case, the data report max is totally 192(24Byte), which is larger than
      128, while max size 128 blocked it as illegal length. So increase the report
      size to satisfy it and more demands in the future.
      Signed-off-by: NSong Hongyan <hongyan.song@intel.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      71f6fa90
  8. 23 7月, 2018 1 次提交
  9. 17 7月, 2018 1 次提交
  10. 25 6月, 2018 1 次提交
  11. 13 6月, 2018 1 次提交
    • K
      treewide: kmalloc() -> kmalloc_array() · 6da2ec56
      Kees Cook 提交于
      The kmalloc() function has a 2-factor argument form, kmalloc_array(). This
      patch replaces cases of:
      
              kmalloc(a * b, gfp)
      
      with:
              kmalloc_array(a * b, gfp)
      
      as well as handling cases of:
      
              kmalloc(a * b * c, gfp)
      
      with:
      
              kmalloc(array3_size(a, b, c), gfp)
      
      as it's slightly less ugly than:
      
              kmalloc_array(array_size(a, b), c, gfp)
      
      This does, however, attempt to ignore constant size factors like:
      
              kmalloc(4 * 1024, gfp)
      
      though any constants defined via macros get caught up in the conversion.
      
      Any factors with a sizeof() of "unsigned char", "char", and "u8" were
      dropped, since they're redundant.
      
      The tools/ directory was manually excluded, since it has its own
      implementation of kmalloc().
      
      The Coccinelle script used for this was:
      
      // Fix redundant parens around sizeof().
      @@
      type TYPE;
      expression THING, E;
      @@
      
      (
        kmalloc(
      -	(sizeof(TYPE)) * E
      +	sizeof(TYPE) * E
        , ...)
      |
        kmalloc(
      -	(sizeof(THING)) * E
      +	sizeof(THING) * E
        , ...)
      )
      
      // Drop single-byte sizes and redundant parens.
      @@
      expression COUNT;
      typedef u8;
      typedef __u8;
      @@
      
      (
        kmalloc(
      -	sizeof(u8) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(__u8) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(char) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(unsigned char) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(u8) * COUNT
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(__u8) * COUNT
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(char) * COUNT
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(unsigned char) * COUNT
      +	COUNT
        , ...)
      )
      
      // 2-factor product with sizeof(type/expression) and identifier or constant.
      @@
      type TYPE;
      expression THING;
      identifier COUNT_ID;
      constant COUNT_CONST;
      @@
      
      (
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * (COUNT_ID)
      +	COUNT_ID, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * COUNT_ID
      +	COUNT_ID, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * (COUNT_CONST)
      +	COUNT_CONST, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * COUNT_CONST
      +	COUNT_CONST, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * (COUNT_ID)
      +	COUNT_ID, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * COUNT_ID
      +	COUNT_ID, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * (COUNT_CONST)
      +	COUNT_CONST, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * COUNT_CONST
      +	COUNT_CONST, sizeof(THING)
        , ...)
      )
      
      // 2-factor product, only identifiers.
      @@
      identifier SIZE, COUNT;
      @@
      
      - kmalloc
      + kmalloc_array
        (
      -	SIZE * COUNT
      +	COUNT, SIZE
        , ...)
      
      // 3-factor product with 1 sizeof(type) or sizeof(expression), with
      // redundant parens removed.
      @@
      expression THING;
      identifier STRIDE, COUNT;
      type TYPE;
      @@
      
      (
        kmalloc(
      -	sizeof(TYPE) * (COUNT) * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE) * (COUNT) * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE) * COUNT * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE) * COUNT * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * (COUNT) * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * (COUNT) * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * COUNT * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * COUNT * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      )
      
      // 3-factor product with 2 sizeof(variable), with redundant parens removed.
      @@
      expression THING1, THING2;
      identifier COUNT;
      type TYPE1, TYPE2;
      @@
      
      (
        kmalloc(
      -	sizeof(TYPE1) * sizeof(TYPE2) * COUNT
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE1) * sizeof(THING2) * (COUNT)
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
        , ...)
      |
        kmalloc(
      -	sizeof(THING1) * sizeof(THING2) * COUNT
      +	array3_size(COUNT, sizeof(THING1), sizeof(THING2))
        , ...)
      |
        kmalloc(
      -	sizeof(THING1) * sizeof(THING2) * (COUNT)
      +	array3_size(COUNT, sizeof(THING1), sizeof(THING2))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE1) * sizeof(THING2) * COUNT
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE1) * sizeof(THING2) * (COUNT)
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
        , ...)
      )
      
      // 3-factor product, only identifiers, with redundant parens removed.
      @@
      identifier STRIDE, SIZE, COUNT;
      @@
      
      (
        kmalloc(
      -	(COUNT) * STRIDE * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	COUNT * (STRIDE) * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	COUNT * STRIDE * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	(COUNT) * (STRIDE) * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	COUNT * (STRIDE) * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	(COUNT) * STRIDE * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	(COUNT) * (STRIDE) * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	COUNT * STRIDE * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      )
      
      // Any remaining multi-factor products, first at least 3-factor products,
      // when they're not all constants...
      @@
      expression E1, E2, E3;
      constant C1, C2, C3;
      @@
      
      (
        kmalloc(C1 * C2 * C3, ...)
      |
        kmalloc(
      -	(E1) * E2 * E3
      +	array3_size(E1, E2, E3)
        , ...)
      |
        kmalloc(
      -	(E1) * (E2) * E3
      +	array3_size(E1, E2, E3)
        , ...)
      |
        kmalloc(
      -	(E1) * (E2) * (E3)
      +	array3_size(E1, E2, E3)
        , ...)
      |
        kmalloc(
      -	E1 * E2 * E3
      +	array3_size(E1, E2, E3)
        , ...)
      )
      
      // And then all remaining 2 factors products when they're not all constants,
      // keeping sizeof() as the second factor argument.
      @@
      expression THING, E1, E2;
      type TYPE;
      constant C1, C2, C3;
      @@
      
      (
        kmalloc(sizeof(THING) * C2, ...)
      |
        kmalloc(sizeof(TYPE) * C2, ...)
      |
        kmalloc(C1 * C2 * C3, ...)
      |
        kmalloc(C1 * C2, ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * (E2)
      +	E2, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * E2
      +	E2, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * (E2)
      +	E2, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * E2
      +	E2, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	(E1) * E2
      +	E1, E2
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	(E1) * (E2)
      +	E1, E2
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	E1 * E2
      +	E1, E2
        , ...)
      )
      Signed-off-by: NKees Cook <keescook@chromium.org>
      6da2ec56
  12. 16 5月, 2018 1 次提交
  13. 26 4月, 2018 1 次提交
    • B
      HID: generic: create one input report per application type · f07b3c1d
      Benjamin Tissoires 提交于
      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: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      f07b3c1d
  14. 23 3月, 2018 1 次提交
  15. 06 3月, 2018 1 次提交
  16. 16 2月, 2018 1 次提交
  17. 07 12月, 2017 1 次提交
  18. 21 11月, 2017 4 次提交
  19. 07 11月, 2017 1 次提交
  20. 17 10月, 2017 2 次提交
    • M
      HID: alps: add new U1 device ID · 287b8e11
      Masaki Ota 提交于
      Add new U1 device Product ID This device is used on HP Elite book x360 series.
      
      [jkosina@suse.cz: update changelog]
      Signed-off-by: NMasaki Ota <masaki.ota@jp.alps.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      287b8e11
    • M
      HID: alps: add support for Alps T4 Touchpad device · 73196ebe
      Masaki Ota 提交于
      - Define T4 device specification value for support T4 device.
      
      - Creeate "t4_contact_data" and "t4_input_report" structure for decoding and
        storing T4-specific data
      
      - Create "t4_calc_check_sum()" function for calculating checksum value to send
        to the device. T4 needs to send this value when reading or writing device
        address value.
      
      - Create "t4_read_write_register()" function for reading and writing device
        address value.
      
      - Create "t4_raw_event()" function for decodin XYZ, palm and button data.
      
      - Replace "MAX_TOUCHES" fixed variable to "max_fingers" variable.
      
      - Add T4 devuce product ID. (0x120C)
      
      T4 device is used on HP EliteBook 1000 series and Zbook Stduio
      
      [jkosina@suse.cz: rewrite changelog]
      Signed-off-by: NMasaki Ota <masaki.ota@jp.alps.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      73196ebe
  21. 11 10月, 2017 1 次提交
  22. 16 9月, 2017 1 次提交
  23. 06 9月, 2017 1 次提交
  24. 01 8月, 2017 1 次提交
  25. 24 7月, 2017 1 次提交
  26. 20 7月, 2017 1 次提交
  27. 22 6月, 2017 1 次提交
  28. 13 6月, 2017 2 次提交
    • J
      HID: let generic driver yield control iff specific driver has been enabled · 0ca4cd7b
      Jiri Kosina 提交于
      There are many situations where generic HID driver provides some basic level
      of support for certain device, but later this support (usually by implementing
      vendor-specific extensions of HID protocol) is extended and the support moved
      over to a separate (usually per-vendor) specific driver.
      
      This might bring a rather unpleasant suprise for users, as all of a sudden
      there is a new config option they have to enable in order to get any support
      for their device whatsoever, although previous kernel versions provided basic
      support through the generic driver. Which is rightfully seen as a regression.
      
      Fix this by including the entry for a particular device in
      hid_have_special_driver[] iff the specific config option has been specified,
      and let generic driver handle the device otherwise.
      Also make the behavior of hid_scan_report() (where the same decision is being
      taken on a per-report level) consistent.
      
      While at it, reshuffle the hid_have_special_driver[] a bit to restore the
      alphabetical ordering (first order by config option, and within those
      sections order by VID).
      
      This is considered a short-term solution, before generic way of giving
      precedence to special drivers and falling back to generic driver is
      figured out.
      
      While at it, fixup a missing entry for GFRM driver; thanks to Hans de Geode for
      spotting this (and for discovering a few issues in the conversion).
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      0ca4cd7b
    • A
      HID: core: don't use negative operands when shift · 08585e43
      Andy Shevchenko 提交于
      The recent C standard in 6.5.7 paragraph 4 defines that operands for
      bitwise shift operators should be non-negative, otherwise it's an
      undefined behaviour.
      Signed-off-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      08585e43
  29. 12 6月, 2017 1 次提交
  30. 08 6月, 2017 3 次提交
  31. 22 5月, 2017 1 次提交