1. 07 2月, 2014 1 次提交
  2. 04 2月, 2014 1 次提交
  3. 11 12月, 2013 1 次提交
  4. 21 5月, 2013 1 次提交
  5. 15 4月, 2013 1 次提交
  6. 24 12月, 2012 1 次提交
  7. 27 10月, 2012 1 次提交
    • D
      [media] rc-core: add separate defines for protocol bitmaps and numbers · c003ab1b
      David Härdeman 提交于
      The RC_TYPE_* defines are currently used both where a single protocol is
      expected and where a bitmap of protocols is expected.
      
      Functions like rc_keydown() and functions which add/remove entries to the
      keytable want a single protocol. Future userspace APIs would also
      benefit from numeric protocols (rather than bitmap ones). Keytables are
      smaller if they can use a small(ish) integer rather than a bitmap.
      
      Other functions or struct members (e.g. allowed_protos,
      enabled_protocols, etc) accept multiple protocols and need a bitmap.
      
      Using different types reduces the risk of programmer error. Using a
      protocol enum whereever possible also makes for a more future-proof
      user-space API as we don't need to worry about a sufficient number of
      bits being available (e.g. in structs used for ioctl() calls).
      
      The use of both a number and a corresponding bit is dalso one in e.g.
      the input subsystem as well (see all the references to set/clear bit when
      changing keytables for example).
      
      This patch separate the different usages in preparation for
      upcoming patches.
      
      Where a single protocol is expected, enum rc_type is used; where one or more
      protocol(s) are expected, something like u64 is used.
      
      The patch has been rewritten so that the format of the sysfs "protocols"
      file is no longer altered (at the loss of some detail). The file itself
      should probably be deprecated in the future though.
      Signed-off-by: NDavid Härdeman <david@hardeman.nu>
      Cc: Andy Walls <awalls@md.metrocast.net>
      Cc: Maxim Levitsky <maximlevitsky@gmail.com>
      Cc: Antti Palosaari <crope@iki.fi>
      Cc: Mike Isely <isely@pobox.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      c003ab1b
  8. 21 5月, 2012 1 次提交
  9. 20 5月, 2012 1 次提交
  10. 11 4月, 2012 1 次提交
    • A
      [media] ati_remote: add support for Medion X10 Digitainer remote · 9d454d48
      Anssi Hannula 提交于
      Add support for another Medion X10 remote. This was apparently
      originally used with the Medion Digitainer box, but is now sold
      separately without any Digitainer labeling.
      
      A peculiarity of this remote is a scrollwheel in place of up/down
      buttons. Each direction is mapped to 8 different scancodes, each
      corresponding to 1..8 notches, allowing multiple notches to the same
      direction to be transmitted in a single scancode. The driver transforms
      the multi-notch scancodes to multiple events of the single-notch
      scancode.
      (0x70..0x77 = 1..8 notches down, 0x78..0x7f = 1..8 notches up)
      
      Since the scrollwheel scancodes are the same that are used for mouse on
      some other X10 (ati_remote) remotes, the driver will now check whether
      the active keymap has a keycode defined for the single-notch scancode
      when a mouse/scrollwheel scancode (0x70..0x7f) is received. If set,
      scrollwheel is assumed, otherwise mouse is assumed.
      
      This remote ships with a different receiver than the already supported
      Medion X10 remote, but they share the same USB ID. The only difference
      in the USB descriptors is that the Digitainer receiver has the Remote
      Wakeup bit set in bmAttributes of the Configuration Descriptor.
      Therefore that is used to select the default keymap.
      
      Thanks to Stephan Raue from OpenELEC (www.openelec.tv) for providing me
      both a Medion X10 Digitainer remote+receiver and an already supported
      Medion X10 remote+receiver. Thanks to Martin Beyss for providing some
      useful information about the remote (including the "Digitainer" name).
      This patch has been tested by both of them and myself.
      Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
      Tested-by: NStephan Raue <stephan@openelec.tv>
      Tested-by: NMartin Beyss <Martin.Beyss@rwth-aachen.de>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      9d454d48
  11. 08 3月, 2012 1 次提交
  12. 15 2月, 2012 1 次提交
  13. 11 1月, 2012 1 次提交
  14. 24 11月, 2011 1 次提交
  15. 22 9月, 2011 3 次提交
  16. 28 7月, 2011 1 次提交
    • J
      [media] rc-core support for Microsoft IR keyboard/mouse · f5f2cc64
      Jarod Wilson 提交于
      This is a custom IR protocol decoder, for the RC-6-ish protocol used by
      the Microsoft Remote Keyboard, apparently developed internally at
      Microsoft, and officially dubbed MCIR-2, per their March 2011 remote and
      transceiver requirements and specifications document, which also touches
      on this IR keyboard/mouse device.
      
      Its a standard keyboard with embedded thumb stick mouse pointer and
      mouse buttons, along with a number of media keys. The media keys are
      standard RC-6, identical to the signals from the stock MCE remotes, and
      will be handled as such. The keyboard and mouse signals will be decoded
      and delivered to the system by an input device registered specifically
      by this driver.
      
      Successfully tested with multiple mceusb-driven transceivers, as well as
      with fintek-cir and redrat3 hardware. Essentially, any raw IR hardware
      with enough sampling resolution should be able to use this decoder,
      nothing about it is at all receiver-hardware-specific.
      
      This work is inspired by lirc_mod_mce:
      
      The documentation there and code aided in understanding and decoding the
      protocol, but the bulk of the code is actually borrowed more from the
      existing in-kernel decoders than anything. I did recycle the keyboard
      keycode table, a few defines, and some of the keyboard and mouse data
      parsing bits from lirc_mod_mce though.
      
      Special thanks to James Meyer for providing the hardware, and being
      patient with me as I took forever to get around to writing this.
      
      callback routine to ensure we don't get any stuck keys, and used
      symbolic names for the keytable. Also cc'ing Florian this time, who I
      believe is the original mod-mce author...
      
      CC: Florian Demski <fdemski@users.sourceforge.net>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      f5f2cc64
  17. 20 5月, 2011 1 次提交
  18. 23 3月, 2011 1 次提交
    • M
      [media] rc/keymaps: Rename Hauppauge table as rc-hauppauge · 15195d3a
      Mauro Carvalho Chehab 提交于
      There are two "hauppauge-new" keymaps, one with protocol
      unknown, and the other with the protocol marked accordingly.
      However, both tables are miss-named.
      
      Also, the old rc-hauppauge-new is broken, as it mixes
      three different controllers as if they were just one.
      
      This patch solves half of the problem by renaming the
      correct keycode table as just rc-hauppauge. This table
      contains the codes for the four different types of
      remote controllers found on Hauppauge cards, properly
      mapped with their different addresses.
      
       create mode 100644 drivers/media/rc/keymaps/rc-hauppauge.c
       delete mode 100644 drivers/media/rc/keymaps/rc-rc5-hauppauge-new.c
      [Jarod: fix up RC_MAP_HAUPPAUGE defines]
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      15195d3a
  19. 22 3月, 2011 2 次提交
  20. 29 12月, 2010 6 次提交
  21. 23 10月, 2010 2 次提交
  22. 21 10月, 2010 10 次提交