1. 04 4月, 2016 1 次提交
  2. 01 4月, 2016 1 次提交
    • Y
      HID: Asus X205TA keyboard driver · eeb01a57
      Yusuke Fujimaki 提交于
      Asus X205TA built-in keyboard contains wrong
      logical maximum value in report descriptor.
      
      0x05, 0x01,  // Usage Page (Generic Desktop)
      0x09, 0x06,  // Usage (Keyboard)
      0xa1, 0x01,  // Collection (Application)
      0x85, 0x01,  // Report ID (1)
      0x05, 0x07,  // Usage Page (Keyboard/Keypad)
      0x19, 0xe0,  // Usage Minimum (224)
      0x29, 0xe7,  // Usage Maximum (231)
      0x15, 0x00,  // Logical Minimum (0)
      0x25, 0x01,  // Logical Maximum (1)
      0x75, 0x01,  // Report Size (1)
      0x95, 0x08,  // Report Count (8)
      0x81, 0x02,  // Input (Data,Array,Abs)
      0x95, 0x01,  // Report Count (1)
      0x75, 0x08,  // Report Size (8)
      0x81, 0x03,  // Input (Const,Var,Abs)
      0x95, 0x05,  // Report Count (5)
      0x75, 0x01,  // Report Size (1)
      0x05, 0x08,  // Usage (LED)
      0x19, 0x01,  // Usage Minimum (1)
      0x29, 0x05,  // Usage Maximum (5)
      0x91, 0x02,  // Output (Data,Var,Abs)
      0x95, 0x01,  // Report Count (1)
      0x75, 0x03,  // Report Size (3)
      0x91, 0x03,  // Output (Const,Var,Abs)
      0x95, 0x06,  // Report Count (6)
      0x75, 0x08,  // Report Size (8)
      0x15, 0x00,  // Logical Minimum (0)
      0x25, 0x65,  // Logical Maximum (101)  * too small *
      0x05, 0x07,  // Usage Page (Keyboard/Keypad)
      0x19, 0x00,  // Usage Minimum (0)
      0x29, 0xdd,  // Usage Maximum (221)
      0x81, 0x00,  // Input(Data,Array,Abs)
      
      In Asus X205TA japanese keyboard model,there are language
      specific keys over usage id 101.
      This patch correct wrong logical maximum in report
      descriptor.
      Signed-off-by: NYusuke Fujimaki <usk.fujimaki@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      eeb01a57
  3. 02 3月, 2016 1 次提交
  4. 26 10月, 2015 1 次提交
  5. 01 10月, 2015 1 次提交
  6. 04 9月, 2015 1 次提交
  7. 18 8月, 2015 1 次提交
  8. 24 7月, 2015 1 次提交
  9. 12 6月, 2015 1 次提交
  10. 11 4月, 2015 1 次提交
    • S
      HID: sensor: Custom and Generic sensor support · 4a7de051
      Srinivas Pandruvada 提交于
      HID Sensor Spec defines two usage ids for custom sensors
      
      	HID_USAGE_SENSOR_TYPE_OTHER_CUSTOM (0x09, 0xE1)
      	HID_USAGE_SENSOR_TYPE_OTHER_GENERIC(0x09, 0xE2)
      
      	In addition the standard also defines usage ids for custom fields.
      The purpose of these sensors is to extend the functionality or provide a way to
      obfuscate the data being communicated by a sensor. Without knowing the mapping
      between the data and its encapsulated form, it is difficult for an driver to
      determine what data is being communicated by the sensor.  This allows some
      differentiating use cases, where vendor can provide applications.  Since these
      can't be represented by standard sensor interfaces like IIO, we present these
      as fields with
      
      - type (input/output)
      - units
      - min/max
      - get/set value
      
      In addition an dev interface to transfer report events. Details about this
      interface is described in /Documentation/hid/hid-sensor.txt.  Manufacturers
      should not use these ids for any standard sensors, otherwise the the
      product/vendor id can be added to black list.
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Reviewed-by: NJonathan Cameron <jic23@kernel.org>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      4a7de051
  11. 16 3月, 2015 2 次提交
    • S
      HID: plantronics: fix Kconfig default · f1088b38
      Stefan Richter 提交于
      This driver didn't exist until before v3.19.
      Why would suddenly everybody want to build it?
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      f1088b38
    • J
      HID: Stop hiding options with !EXPERT · 7af05e73
      Jean Delvare 提交于
      Many HID driver options are hidden unless EXPERT is set. While I
      understand the idea of simplifying the kernel configuration for most
      users, in practice I believe it adds more confusion than it helps.
      
      One thing that worries me is that, in non-EXPERT mode, these drivers
      will be either built-in or modular based on apparent magic. For
      example, switching INPUT and HID from m to y will cause all these
      drivers to be built into the kernel when they were previously built
      as modules. Short of enabling EXPERT mode altogether, the user has no
      control over that.
      
      Generally I do not think tristate options should depend on !EXPERT.
      Of these, 11 of 15 are currently in the hid subsystem.
      
      The HID_LOGITECH option is even worse than the others. Sub-options
      depend on it, and this causes menuconfig and friends to display the
      option even though the user can't change its value. The help page for
      HID_LOGITECH will not explain why the value can't be changed. It only
      says, for example:
      
        Depends on: INPUT [=y] && HID [=y]
      
      and that leaves the user puzzled about why the option is forced to y.
      You might argue that this is a Kconfig bug, but that doesn't make it
      less annoying for the user.
      
      Even worse is that some of the sub-options of HID_LOGITECH select
      INPUT_FF_MEMLESS, which in turn gets out of control for the user. So,
      if you set INPUT=y and HID=y (something most general purpose
      distributions would do these days, as both modules would get loaded on
      a vast majority of systems otherwise), and you want support for
      force-feedback game controllers, you can't have that as a module, it
      has to be built-in, regardless of how rare these devices are.
      
      Of course, all this madness goes away once EXPERT is enabled, but then
      the rest of the kernel configuration becomes more complex, which
      totally voids the original point.
      
      For this reason, I would like all HID device tristate options to be
      displayed regardless of EXPERT being set or not. We can let the
      default settings still depend on EXPERT, that's not intrusive.
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      7af05e73
  12. 05 3月, 2015 1 次提交
  13. 04 3月, 2015 1 次提交
  14. 07 1月, 2015 1 次提交
  15. 22 12月, 2014 1 次提交
  16. 18 12月, 2014 1 次提交
  17. 05 11月, 2014 1 次提交
  18. 03 11月, 2014 1 次提交
  19. 29 10月, 2014 2 次提交
  20. 04 9月, 2014 1 次提交
  21. 07 8月, 2014 1 次提交
  22. 29 7月, 2014 2 次提交
  23. 26 7月, 2014 1 次提交
  24. 01 7月, 2014 1 次提交
  25. 11 6月, 2014 2 次提交
  26. 21 5月, 2014 1 次提交
  27. 09 4月, 2014 1 次提交
  28. 18 2月, 2014 2 次提交
  29. 04 2月, 2014 1 次提交
  30. 03 2月, 2014 1 次提交
  31. 03 12月, 2013 1 次提交
    • O
      HID: logitech-dj: add HIDRAW dependency in Kconfig · dcdc50e7
      Olivier Gay 提交于
      hid-logitech-dj.c driver needs hidraw to work correctly. Without
      hidraw, hid-logitech-dj.c fails during probe() and Logitech
      Unifying devices HID reports aren't recognized.
      
      The unifying receiver has 3 usb interfaces. When hid-logitech-dj driver is
      loaded, interfaces 0 and 1 are discarded.
      
      Interface 2 consists of a hid class interface with 3 collections, each of
      which sports the 'vendor' usage, thus, there is no reason for hid_input to
      claim any of them. On the other hand, hidraw has no issue in claiming the
      collections, even if they are 'vendor'. As of today, hid-logitech-dj uses
      hidraw api to send configuration/control reports to interface 2 of the
      Unifying receiver.
      
      Without the hid-logitech-dj driver, interfaces 0 and 1 are claimed by
      hid-input, as they correspond to a keyboard and a mouse. But that is not
      relevant to the discussion.
      
      [jkosina@suse.cz: make the changelog more verbose, thanks to Nestor]
      Signed-off-by: NOlivier Gay <ogay@logitech.com>
      Signed-off-by: NNestor Lopez Casado <nlopezcasad@logitech.com>
      Signed-off-by: NMathieu Meisser <mmeisser@logitech.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      dcdc50e7
  32. 21 11月, 2013 1 次提交
  33. 11 11月, 2013 1 次提交
    • S
      HID: sony: Add force feedback support for Dualshock3 USB · a08c22c0
      Sven Eckelmann 提交于
      Sony Dualshock 3 controllers have two motors which can be used to provide
      simple force feedback rumble effects. The right motor is can be used to create
      a weak rumble effect but does not allow to set the force. The left motor is
      used to create a strong rumble effect with adjustable intensity.
      
      The state of both motors can be changed using HID_OUTPUT_REPORT packets and
      have no timing information. FF memless is used to keep track of the timing and
      the sony driver just generates the necessary URBs.
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      a08c22c0
  34. 30 10月, 2013 1 次提交
  35. 25 10月, 2013 1 次提交