1. 17 5月, 2010 2 次提交
  2. 29 4月, 2010 1 次提交
    • W
      HID: add support for BTC Emprex 3009URF III Vista MCE Remote · bf280628
      Wayne Thomas 提交于
      The Behavior Tech. Computer Corp. (BTC) remote branded as "Emprex 3009URF III
      Vista Remote Controller" uses non-standard mappings for all of its 'special
      purpose' keys (0xffbc usage page).  This patch modifies the existing
      hid-topseed quirky driver to support both remotes in order to prevent
      proliferation of in-kernel quirky drivers until such a time that udev remapping
      works with these devices.  Tested successfully with both the "Emprex" remote
      and the "CyberLink" remote originally supported by the hid-topseed driver.
      Signed-off-by: NWayne Thomas <waynethomas69@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      bf280628
  3. 23 4月, 2010 1 次提交
  4. 21 4月, 2010 1 次提交
  5. 19 4月, 2010 1 次提交
    • B
      HID: add HID_QUIRK_HIDDEV_FORCE and HID_QUIRK_NO_IGNORE · b5e5a37e
      Bastien Nocera 提交于
      Add two quirks to make it possible for usbhid module options to
      override whether a device is ignored (HID_QUIRK_NO_IGNORE) and
      whether to connect a hiddev device (HID_QUIRK_HIDDEV_FORCE).
      
      Passing HID_QUIRK_NO_IGNORE for your device means that it will
      not be ignored by the HID layer, even if present in a blacklist.
      
      HID_QUIRK_HIDDEV_FORCE will force the creation of a hiddev for that
      device, making it accessible from user-space.
      
      Tested with an Apple IR Receiver, switching it from using appleir
      to using lirc's macmini driver.
      Signed-off-by: NBastien Nocera <hadess@hadess.net>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      b5e5a37e
  6. 13 4月, 2010 1 次提交
    • P
      HID: non-overlapping zeroing of extra bits · 75c28df8
      Pete Zaitcev 提交于
      From my review of the way the unused bits of report are being zeroed,
      it seems like there must be a bug. Currently, the zeroing is done
      in hid_output_field and it covers any bits between the last used bit
      and the end of the byte. But in case of, say, my keyboard, NumLock is
      mask 0x01 and CapsLock is 0x02. Invoking hid_output_field for NumLock
      definitely zeroes across CapsLock. The only reason this works is that
      the fields are sorted by the offset.
      
      It would be more correct and simpler to zero-fill the buffer into
      which the fields are set.
      
      The patch is tested with an IBM keyboard that is improperly sensitive
      to out-of-report pad bits, the extra bits are still zeroed and the
      fields continue to work as expected. It is also tested with good
      keyboards.
      
      In case, a related bug in RHEL 5 is tracked with Red Hat bug 513934.
      Signed-off-by: NPete Zaitcev <zaitcev@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      75c28df8
  7. 12 4月, 2010 1 次提交
  8. 15 3月, 2010 1 次提交
  9. 10 2月, 2010 3 次提交
  10. 03 2月, 2010 3 次提交
  11. 26 1月, 2010 1 次提交
  12. 13 1月, 2010 4 次提交
  13. 05 1月, 2010 1 次提交
  14. 04 1月, 2010 1 次提交
  15. 23 12月, 2009 1 次提交
  16. 10 12月, 2009 1 次提交
  17. 03 12月, 2009 1 次提交
  18. 13 11月, 2009 1 次提交
  19. 14 10月, 2009 3 次提交
  20. 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
  21. 17 9月, 2009 1 次提交
  22. 15 9月, 2009 1 次提交
  23. 26 8月, 2009 1 次提交
  24. 08 8月, 2009 2 次提交
  25. 23 7月, 2009 3 次提交
  26. 20 7月, 2009 1 次提交
  27. 26 6月, 2009 1 次提交