1. 19 7月, 2010 2 次提交
  2. 31 5月, 2010 1 次提交
  3. 25 5月, 2010 1 次提交
    • S
      HID: roccat: propagate special events of roccat hardware to userspace · 206f5f2f
      Stefan Achatz 提交于
      Module roccat is a char device used to report special events of roccat hardware
      to userland. These events include requests for on-screen-display of profile or
      dpi settings or requests for execution of macro sequences that are not stored
      in device. The information in these events depends on hid device implementation
      and contains data that is not available in a single hid event or else hidraw
      could have been used.
      
      It is inspired by hidraw, but uses only one circular buffer for all readers.
      The device is as generic as possible so that the functionality is usable by all
      (kone and upcomming) roccat device drivers.
      Signed-off-by: NStefan Achatz <erazor_de@users.sourceforge.net>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      206f5f2f
  4. 21 5月, 2010 1 次提交
    • J
      HID: fix up 'EMBEDDED' mess in Kconfig · 73d5e8f7
      Jiri Kosina 提交于
      The whole point of making some of the drivers automatically selected
      unless 'EMBEDDED' was to handle quirks transparently after their separation
      from the generic core.
      
      Over time, some of the later-added quirks grew into more standalone drivers,
      implementing non-trivial features a being larger than a few bytes of code.
      
      In addition to that, some of the standalone drivers don't make sense for
      99.9% of the users, as they are very specific to rare devices.
      
      Therefore build by default in only those drivers which
      
      - we historically used to support even before quirk separation from the
        core code
      - are isolated enough and likely to hit quite large portion of the
        users anyway (Microsoft, Logitech)
      Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      73d5e8f7
  5. 17 5月, 2010 2 次提交
  6. 12 5月, 2010 2 次提交
  7. 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
  8. 15 4月, 2010 1 次提交
  9. 12 4月, 2010 1 次提交
  10. 11 4月, 2010 1 次提交
  11. 31 3月, 2010 6 次提交
  12. 22 3月, 2010 2 次提交
    • J
      HID: fixup Kconfig entry for Roccat Kone · 23d386d8
      Jiri Kosina 提交于
      Make it independent on CONFIG_EMBEDDED (to be in sync with other
      "full-fledged" HID drivers which are not simple quirks) and provide
      a little bit better text description.
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      23d386d8
    • S
      HID: add driver for Roccat Kone gaming mouse · 14bf62cd
      Stefan Achatz 提交于
      This Patch adds support for Kone gaming mouse from Roccat.
      It provides access to profiles, settings, firmware, weight,
      actual settings etc. through sysfs attributes.
      Event handling of this mouse differs from standard hid behaviour
      in that tilt button press is reported in each move event which
      results in strange behaviour if not handled by the driver.
      
      This is a heavily reworked version of the previously introduced driver.
      The changes include most of the previously raised concerns,
      memory leak and other fixes, code cleanups, adoption of additional
      achieved knowlege about the hardware and is (IMHO) a much better version
      than before even when I exchanged reduced USB-IO with a bigger memory
      consumption.
      
      I refused to implement one mentioned point:
      Removing the 'just-because-we-can' attributes. Motivation:
      Reading the clipped in weight: I'm no gamer and can't determine the
      usefulness of this feature but if the manufacturer implements such a
      feature it might make sense to someone and I would unwillingly limit the
      functionality besides its such a small feature.
      Reading the actual profile and dpi settings: Here I can testify that one
      can get lost of the actual settings when switching back and forth.
      The manufacturers windows driver has the ability for on-screen-display
      of the values and there is a mouse in the market that has an lcd on the
      underside of it to show these values. So I think this feature makes sense
      not only for me and shouldn't be removed.
      Signed-off-by: NStefan Achatz <erazor_de@users.sourceforge.net>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      14bf62cd
  13. 16 3月, 2010 1 次提交
  14. 10 2月, 2010 3 次提交
  15. 03 2月, 2010 1 次提交
    • J
      HID: make full-fledged hid-bus drivers properly selectable · 2dbf209d
      Jiri Kosina 提交于
      For historical reasons, we don't have most of the in-tree
      drivers residing on hid-bus properly selectable in kernel
      configuration unless CONFIG_EMBEDDED is set.
      
      This has been introduced on Linus' request from 14 Oct
      
      ===
      As to the Kconfig options - do they really add so much space that you need to
      ask for the quirks? You didn't use to. Can you make the questions depend on
      EMBEDDED, or at least on the HID_COMPAT thing or whatever?
      ===
      
      This still makes perfect sense for small and tiny drivers, which
      just fix report descriptors, fix up HID->input mappings that slightly
      violates HUT standard, send one extra packet to the device that is
      needed before it becomes functional, etc.
      
      Since then, we have been gathering more and more HID-bus drivers,
      which are full-fledged drivers. For these, the size argument becomes
      more valid. Plus the devices are much more special than "just violates
      HID specification in this one or two tiny unimportant points".
      
      Therefore I am marking such drivers as properly selectable no matter
      the setting of CONFIG_EMBEDDED, while keeping all the small and tiny
      ones compiled by default.
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      2dbf209d
  16. 26 1月, 2010 1 次提交
  17. 13 1月, 2010 2 次提交
  18. 04 1月, 2010 2 次提交
  19. 23 12月, 2009 2 次提交
  20. 17 9月, 2009 1 次提交
  21. 23 7月, 2009 3 次提交
  22. 12 6月, 2009 1 次提交
    • J
      HID: use debugfs for report dumping descriptor · a635f9dd
      Jiri Kosina 提交于
      It is a little bit inconvenient for people who have some non-standard
      HID hardware (usually violating the HID specification) to have to
      recompile kernel with CONFIG_HID_DEBUG to be able to see kernel's perspective
      of the HID report descriptor and observe the parsed events. Plus the messages
      are then mixed up inconveniently with the rest of the dmesg stuff.
      
      This patch implements /sys/kernel/debug/hid/<device>/rdesc file, which
      represents the kernel's view of report descriptor (both the raw report
      descriptor data and parsed contents).
      
      With all the device-specific debug data being available through debugfs, there
      is no need for keeping CONFIG_HID_DEBUG, as the 'debug' parameter to the
      hid module will now only output only driver-specific debugging options, which has
      absolutely minimal memory footprint, just a few error messages and one global
      flag (hid_debug).
      
      We use the current set of output formatting functions. The ones that need to be
      used both for one-shot rdesc seq_file and also for continuous flow of data
      (individual reports, as being sent by the device) distinguish according to the
      passed seq_file parameter, and if it is NULL, it still output to kernel ringbuffer,
      otherwise the corresponding seq_file is used for output.
      
      The format of the output is preserved.
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      a635f9dd
  23. 15 5月, 2009 2 次提交