An error occurred fetching the project authors.
  1. 30 Jan, 2017 1 commit
  2. 09 Jul, 2016 1 commit
  3. 19 Nov, 2015 1 commit
  4. 19 Aug, 2015 1 commit
  5. 14 May, 2015 1 commit
    • James Hogan's avatar
      [media] rc: ir-rc5-decoder: Add encode capability · a0466f15
      James Hogan authored
      Add the capability to encode RC-5, RC-5X and RC-5-SZ scancodes as raw
      events. The protocol is chosen based on the specified protocol mask,
      and whether all the required bits are set in the scancode mask, and
      none of the unused bits are set in the scancode data. For example a
      scancode filter with bit 16 set in both data and mask is unambiguously
      RC-5X.
      
      The Manchester modulation helper is used, and for RC-5X it is used twice
      with two sets of timings, the first with a short trailer space for the
      space in the middle, and the second with no leader so that it can
      continue the space.
      
      The encoding in RC-5-SZ first inserts a pulse and then simply utilizes
      the generic Manchester encoder available in rc-core.
      Signed-off-by: default avatarJames Hogan <james@albanarts.com>
      Signed-off-by: default avatarAntti Seppälä <a.seppala@gmail.com>
      Cc: David Härdeman <david@hardeman.nu>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      a0466f15
  6. 30 Oct, 2014 1 commit
  7. 30 Jul, 2014 1 commit
  8. 25 Jul, 2014 2 commits
    • David Härdeman's avatar
      [media] rc-core: merge rc5 and streamzap decoders · e87b540b
      David Härdeman authored
      Now that the protocol is part of the scancode, it is pretty easy to merge
      the rc5 and streamzap decoders. An additional advantage is that the decoder
      is now stricter as it waits for the trailing silence before determining that
      a command is a valid rc5/streamzap command (which avoids collisions that I've
      seen with e.g. Sony protocols).
      Signed-off-by: default avatarDavid Härdeman <david@hardeman.nu>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      e87b540b
    • David Härdeman's avatar
      [media] rc-core: remove protocol arrays · c5540fbb
      David Härdeman authored
      The basic API of rc-core used to be:
      
      	dev = rc_allocate_device();
      	dev->x = a;
      	dev->y = b;
      	dev->z = c;
      	rc_register_device();
      
      which is a pretty common pattern in the kernel, after the introduction of
      protocol arrays the API looks something like:
      
      	dev = rc_allocate_device();
      	dev->x = a;
      	rc_set_allowed_protocols(dev, RC_BIT_X);
      	dev->z = c;
      	rc_register_device();
      
      There's no real need for the protocols to be an array, so change it
      back to be consistent (and in preparation for the following patches).
      
      [m.chehab@samsung.com: added missing changes at some files]
      Signed-off-by: default avatarDavid Härdeman <david@hardeman.nu>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      c5540fbb
  9. 24 Jul, 2014 1 commit
    • David Härdeman's avatar
      [media] rc-core: document the protocol type · 120703f9
      David Härdeman authored
      Right now the protocol information is not preserved, rc-core gets handed a
      scancode but has no idea which protocol it corresponds to.
      
      This patch (which required reading through the source/keymap for all drivers,
      not fun) makes the protocol information explicit which is important
      documentation and makes it easier to e.g. support multiple protocols with one
      decoder (think rc5 and rc-streamzap). The information isn't used yet so there
      should be no functional changes.
      
      [m.chehab@samsung.com: rebased, added cxusb and removed bad whitespacing]
      Signed-off-by: default avatarDavid Härdeman <david@hardeman.nu>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      120703f9
  10. 11 Mar, 2014 1 commit
  11. 07 Feb, 2014 1 commit
  12. 23 Mar, 2013 1 commit
  13. 27 Oct, 2012 1 commit
    • David Härdeman's avatar
      [media] rc-core: add separate defines for protocol bitmaps and numbers · c003ab1b
      David Härdeman authored
      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: default avatarDavid 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: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      c003ab1b
  14. 31 Oct, 2011 1 commit
  15. 29 Dec, 2010 5 commits
  16. 21 Oct, 2010 1 commit
  17. 02 Aug, 2010 3 commits
    • David Härdeman's avatar
      V4L/DVB: ir-core: move decoding state to ir_raw_event_ctrl · c216369e
      David Härdeman authored
      This patch moves the state from each raw decoder into the
      ir_raw_event_ctrl struct.
      
      This allows the removal of code like this:
      
              spin_lock(&decoder_lock);
              list_for_each_entry(data, &decoder_list, list) {
                      if (data->ir_dev == ir_dev)
                              break;
              }
              spin_unlock(&decoder_lock);
              return data;
      
      which is currently run for each decoder on each event in order
      to get the client-specific decoding state data.
      
      In addition, ir decoding modules and ir driver module load
      order is now independent. Centralizing the data also allows
      for a nice code reduction of about 30% per raw decoder as
      client lists and client registration callbacks are no longer
      necessary (but still kept around for the benefit of the lirc
      decoder).
      
      Out-of-tree modules can still use a similar trick to what
      the raw decoders did before this patch until they are merged.
      Signed-off-by: default avatarDavid Härdeman <david@hardeman.nu>
      Acked-by: default avatarJarod Wilson <jarod@redhat.com>
      Tested-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      c216369e
    • David Härdeman's avatar
      V4L/DVB: ir-core: centralize sysfs raw decoder enabling/disabling · 667c9ebe
      David Härdeman authored
      With the current logic, each raw decoder needs to add a copy of the exact
      same sysfs code. This is both unnecessary and also means that (re)loading
      an IR driver after raw decoder modules have been loaded won't work as
      expected.
      
      This patch moves that logic into ir-raw-event and adds a single sysfs
      file per device.
      
      Reading that file returns something like:
      
      	"rc5 [rc6] nec jvc [sony]"
      
      (with enabled protocols in [] brackets)
      
      Writing either "+protocol" or "-protocol" to that file will
      enable or disable the according protocol decoder.
      
      An additional benefit is that the disabling of a decoder will be
      remembered across module removal/insertion so a previously
      disabled decoder won't suddenly be activated again. The default
      setting is to enable all decoders.
      
      This is also necessary for the next patch which moves even more decoder
      state into the central raw decoding structs.
      Signed-off-by: default avatarDavid Härdeman <david@hardeman.nu>
      Acked-by: default avatarJarod Wilson <jarod@redhat.com>
      Tested-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      667c9ebe
    • Jarod Wilson's avatar
      V4L/DVB: IR: only initially registers protocol that matches loaded keymap · 7366646e
      Jarod Wilson authored
      Rather than registering all IR protocol decoders as enabled when bringing
      up a new device, only enable the IR protocol decoder that matches the
      keymap being loaded. Additional decoders can be enabled on the fly by
      those that need to, either by twiddling sysfs bits or by using the
      ir-keytable util from v4l-utils.
      
      Functional testing done with the mceusb driver, and it behaves as expected,
      only the rc6 decoder is enabled, keys are all handled properly, etc.
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      7366646e
  18. 19 May, 2010 12 commits
  19. 18 May, 2010 4 commits