1. 27 Aug, 2011 5 commits
    • Jarod Wilson's avatar
      [media] mceusb: query device for firmware emulator version · ab1072eb
      Jarod Wilson authored
      Supposedly, there are essentially three different classes of devices
      that are compatible with Microsoft's specs. First are the "legacy"
      devices, which are built using Microsoft-provided hardware specs and
      firmware. Second are "emulator" devices, which are built using custom
      hardware and firmware, written to emulate Microsoft's firmware. Third
      are "port" devices, which have their own device driver and firmware,
      which provides compatible data to higher levels of the stack.
      
      >From what I can tell, things like nuvoton-cir and fintek-cir are
      essentially "port" devices -- their raw IR buffer format is very similar
      to that of the mceusb devices. Now, within the mceusb driver, we have
      three different "generations", which at first, seemed like maybe they
      mapped to emulator versions. Unfortuantely, every single device I have
      responds "illegal command" to the query to get firmware emulator version
      from the hardware, which means they're either all emulator version 1, or
      they're legacy devices, and our different "generations" aren't at all
      related here. Though in theory, its possible the gen1 devices are
      "legacy" devices and the rest are emulator v1. There are some useful
      features of the v2 interface I was hoping to play with, but alas...
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      ab1072eb
    • Jarod Wilson's avatar
      [media] mceusb: issue device resume cmd when needed · 4840b788
      Jarod Wilson authored
      According to MS docs, the device firmware may halt after receiving an
      unknown instruction, but that it should be possible to tell the firmware
      to continue running by simply sending a device resume command. So lets
      do that.
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      4840b788
    • Jarod Wilson's avatar
      [media] mceusb: set wakeup bits for IR-based resume · fa334898
      Jarod Wilson authored
      Its not uncommon for folks to force these bits enabled, because people
      do want to wake their htpc kit via their remote. Lets just set the bits
      for 'em.
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      fa334898
    • Jarod Wilson's avatar
      [media] mceusb: give hardware time to reply to cmds · 417c0a23
      Jarod Wilson authored
      Sometimes the init routine is blasting commands out to the hardware
      faster than it can reply. Throw a brief delay in there to give the
      hardware a chance to reply before we send the next command.
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      417c0a23
    • Jarod Wilson's avatar
      [media] mceusb: command/response updates from MS docs · a6fbd3b7
      Jarod Wilson authored
      I was recently pointed to the document titled
      Windows-Media-Center-RC-IR-Collection-Green-Button-Specification-03-08-2011-V2.pdf
      which as of this writing, is publicly available from
      download.microsoft.com. It covers a LOT of the gaps in the mceusb
      driver, which to this point, was written almost entirely by
      reverse-engineering. First up, I'm updating the defines for all the MCE
      commands and responses to match their names in the spec. More to come...
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      a6fbd3b7
  2. 07 Aug, 2011 2 commits
  3. 06 Aug, 2011 9 commits
  4. 31 Jul, 2011 11 commits
  5. 30 Jul, 2011 13 commits