1. 07 2月, 2014 1 次提交
  2. 06 2月, 2014 1 次提交
    • J
      [media] media: rc: change 32bit NEC scancode format · 18bc1744
      James Hogan 提交于
      Change 32bit NEC scancode format (used by Apple and TiVo remotes) to
      encode the data with the correct bit order. Previously the raw bits were
      used without being bit reversed, now each 16bit half is bit reversed
      compared to before.
      
      So for the raw NEC data:
        (LSB/First) 0xAAaaCCcc (MSB/Last)
      (where traditionally AA=address, aa=~address, CC=command, cc=~command)
      
      We now generate the scancodes:
        (MSB) 0x0000AACC (LSB) (normal NEC)
        (MSB) 0x00AAaaCC (LSB) (extended NEC, address check wrong)
        (MSB) 0xaaAAccCC (LSB) (32-bit NEC, command check wrong)
      
      Note that the address byte order in 32-bit NEC scancodes is different to
      that of the extended NEC scancodes. I chose this way as it maintains the
      order of the bits in the address/command fields, and CC is clearly
      intended to be the LSB of the command if the TiVo codes are anything to
      go by so it makes sense for AA to also be the LSB.
      
      The TiVo keymap is updated accordingly.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
      Cc: Jarod Wilson <jarod@redhat.com>
      Cc: linux-media@vger.kernel.org
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      18bc1744
  3. 11 12月, 2013 1 次提交
  4. 14 10月, 2013 1 次提交
  5. 21 5月, 2013 1 次提交
  6. 15 4月, 2013 2 次提交
  7. 24 12月, 2012 1 次提交
  8. 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
  9. 07 10月, 2012 1 次提交
    • W
      [media] rc-msi-digivox-ii: Add full scan keycodes · b45681a6
      Wolfgang Bail 提交于
      The ir-rc from my MSI DigiVox mini II Version 3 (af9015) will not work since
      kernel 3.2.x.
      
      sudo ir-keytable -t shows:
      
      	1348890734.303273: event MSC: scancode = 317
      	1348890734.303280: event key down: KEY_POWER (0x0074)
      	1348890734.303282: event sync
      	1348890734.553961: event key up: KEY_POWER (0x0074)
      	1348890734.553963: event sync
      	1348890741.303451: event MSC: scancode = 30d
      	1348890741.303457: event key down: KEY_DOWN (0x006c)
      	1348890741.303459: event sync
      	1348890741.553956: event key up: KEY_DOWN (0x006c)
      
      So I changed in rc-msi-digivox-ii.c { 0x0002, KEY_2 }, to { 0x0302, KEY_2 },
      and so on. And now it works well.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      b45681a6
  10. 14 8月, 2012 1 次提交
  11. 21 5月, 2012 1 次提交
  12. 20 5月, 2012 3 次提交
  13. 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
  14. 08 3月, 2012 1 次提交
  15. 15 2月, 2012 1 次提交
  16. 21 1月, 2012 1 次提交
  17. 11 1月, 2012 1 次提交
  18. 11 12月, 2011 1 次提交
  19. 20 11月, 2011 1 次提交
  20. 01 11月, 2011 1 次提交
  21. 24 9月, 2011 1 次提交
  22. 22 9月, 2011 3 次提交
  23. 04 9月, 2011 1 次提交
  24. 28 7月, 2011 1 次提交
  25. 02 7月, 2011 1 次提交
  26. 26 5月, 2011 1 次提交
  27. 21 5月, 2011 1 次提交
  28. 20 5月, 2011 2 次提交
  29. 31 3月, 2011 1 次提交
  30. 23 3月, 2011 5 次提交