Re: Can I expect in-kernel decoding to work out of box?

[Jarod Wilson <jarod@redhat.com>]

On Wed, Jul 28, 2010 at 10:41:27AM -0400, Jon Smirl wrote:
> On Wed, Jul 28, 2010 at 10:24 AM, Maxim Levitsky
...
> > You are right that my remote has  JVC protocol. (at least I am sure now
> > it hasn't NEC, because repeat looks differently).
> >
> > My remote now actually partially works with JVC decoder, it decodes
> > every other keypress.
> >
> > Still, no repeat is supported.
> 
> It probably isn't implemented yet. Jarod has been focusing more on
> getting the basic decoders to work.

More specifically, getting the basic decoders to work with very specific
hardware -- i.e., the mceusb transceivers, and primarily focused only on
RC-6(A) decode w/the mceusb bundled remotes. That, and getting the lirc
bridge driver working for both rx and tx.

Basically, my plan of attack has been to get enough bits in place that we
have a "reference implementation", if you will, of a driver that supports
all in-kernel decoders and the lirc interface, complete with the ability
to do tx[*], and from there, then we can really dig into the in-kernel
decoders and/or work on porting additional drivers to ir-core. I'm more
focused on porting additional drivers to ir-core at the moment than I am
on testing all of the protocol decoders right now.

[*] we still don't have an ir-core "native" tx method, but tx on the
mceusb works quite well using the lirc bridge plugin

-- 
Jarod Wilson
jarod@redhat.com