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

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Em 28-07-2010 07:40, Jon Smirl escreveu:
> On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote:
>>> On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl <jonsmirl@gmail.com> wrote:

>> No its not, its just extended NEC.
> 
> http://www.sbprojects.com/knowledge/ir/nec.htm
> Says the last two bytes should be the complement of each other.
> 
> So for extended NEC it would need to be:
> 1100 0010 1010 0101 instead of 1100 0010 1010 0100
> The last bit is wrong.
> 
> From the debug output it is decoding as NEC, but then it fails a
> consistency check. Maybe we need to add a new protocol that lets NEC
> commands through even if they fail the error checks.

Assuming that Maxim's IR receiver is not causing some bad decode at the
NEC code, it seems simpler to add a parameter at sysfs to relax the NEC
detection. We should add some way, at the userspace table for those RC's
that uses a NEC-like code.

There's another alternative: currently, the NEC decoder produces a 16 bits
code for NEC and a 24 bits for NEC-extended code. The decoder may return a
32 bits code when none of the checksum's match the NEC or NEC-extended standard.

Such 32 bits code won't match a keycode on a 16-bits or 24-bits table, so
there's no risk of generating a wrong keycode, if the wrong consistent check
is due to a reception error.

Btw, we still need to port rc core to use the new tables ioctl's, as cleaning
all keycodes on a 32 bits table would take forever with the current input
events ioctls.

> It may also be
> that the NEC machine rejected it because the timing was so far off
> that it concluded that it couldn't be a NEC messages. The log didn't
> include the exact reason it got rejected. Add some printks at the end
> of the NEC machine to determine the exact reason for rejection.

The better is to discard the possibility of a timing issue before changing
the decoder to accept NEC-like codes without consistency checks.

> The current state machines enforce protocol compliance so there are
> probably a lot of older remotes that won't decode right. We can use
> some help in adjusting the state machines to let out of spec codes
> through.

Yes, but we should take some care to avoid having another protocol decoder to
interpret badly a different protocol. So, I think that the decoders may have
some sysfs nodes to tweak the decoders to accept those older remotes.

We'll need a consistent way to add some logic at the remotes keycodes used by
ir-keycode, in order to allow it to tweak the decoder when a keycode table for
such remote is loaded into the driver.

> User space lirc is much older. Bugs like this have been worked out of
> it. It will take some time to get the kernel implementation up to the
> same level.

True.

Cheers,
Mauro