1. 11 2月, 2010 1 次提交
  2. 10 2月, 2010 3 次提交
  3. 03 2月, 2010 4 次提交
  4. 13 1月, 2010 3 次提交
  5. 12 12月, 2009 2 次提交
  6. 11 12月, 2009 1 次提交
  7. 10 12月, 2009 1 次提交
  8. 03 12月, 2009 2 次提交
  9. 25 11月, 2009 1 次提交
  10. 24 11月, 2009 1 次提交
  11. 13 11月, 2009 1 次提交
  12. 06 11月, 2009 1 次提交
  13. 05 11月, 2009 1 次提交
    • J
      HID: fixup quirk for NCR devices · 5b915d9e
      Jiri Kosina 提交于
      NCR devices are terminally broken by design -- they claim themselves to contain
      proper input applications in their HID report descriptor, but behave very badly
      if treated in standard way.
      
      According to NCR developers, the devices get confused when queried for reports
      in a standard way, rendering them unusable.
      
      NCR is shipping application called "RPSL" that can be used to drive these
      devices through hiddev, under the assumption that in-kernel driver doesn't
      perform initial report query.
      If it does, neither in-kernel nor hiddev-based driver can operate with these
      devices any more.
      
      Introduce a quirk that skips the report query for all NCR devices. The previous
      NOGET quirk was wrong and had been introduced because I misunderstood the nature
      of brokenness of these devices.
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      5b915d9e
  14. 04 11月, 2009 1 次提交
  15. 20 10月, 2009 1 次提交
  16. 14 10月, 2009 3 次提交
  17. 12 10月, 2009 1 次提交
  18. 05 10月, 2009 1 次提交
  19. 01 10月, 2009 1 次提交
    • J
      HID: fix kerneldoc comment for hid_input_report() · ff9b00a2
      Jiri Kosina 提交于
      The kerneldoc comment for 'interrupt' has already confused a lot
      of people, as it is simply wrong. It doesn't carry the information
      about the context, but is used to distinguish between two fundamental
      types of low-level transport transfers -- interrupt vs. control.
      
      Make this clear in the comment.
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      ff9b00a2
  20. 29 9月, 2009 1 次提交
  21. 20 9月, 2009 1 次提交
  22. 17 9月, 2009 2 次提交
  23. 15 9月, 2009 1 次提交
  24. 26 8月, 2009 1 次提交
  25. 20 8月, 2009 1 次提交
    • J
      HID: support larger reports than 64 bytes in hiddev · affbb8c6
      Jiri Kosina 提交于
      hiddev userspace driver uses a rignbuffer to store the parsed usages
      that should be returned through read(). This buffer is 64 bytes long,
      which is sufficient for queueing single USB 1.0 low-speed report, which
      is of maximum size 48 bytes.
      
      There are however USB HID devices which are full-speed USB devices, and
      therefore they are free to produce reports 64 bytes long. This is correctly
      handled by HID core, but read() on hiddev node gets stuck forever, because
      the ring buffer loops infinitely (as it is exactly 64 bytes long as well),
      never advancing the buffer pointer.
      
      Plus, the core driver is ready to handle highspeed devices, so we should be
      able to handle reports from such devices in the hiddev driver as well, which
      means we need larger ringbuffer.
      Reported-by: NMichael Zeisel <michael.zeisel@philips.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      affbb8c6
  26. 18 8月, 2009 1 次提交
  27. 08 8月, 2009 2 次提交