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

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

Em 28-07-2010 18:01, Maxim Levitsky escreveu:
> On Wed, 2010-07-28 at 17:24 +0300, Maxim Levitsky wrote: 
>> On Wed, 2010-07-28 at 10:13 -0300, Mauro Carvalho Chehab wrote: 
>>> 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.
>>
>>
>> I more or less got to the bottom of this.
>>
>>
>> It turns out that ENE reciever has a non linear measurement error.
>> That is the longer sample is, the larger error it contains.
>> Substracting around 4% from the samples makes the output look much more
>> standard compliant.
>>
>> 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.
>>
>> However, all recievers (and transmitters) aren't perfect.
>> Thats why I prefer lirc, because it makes no assumptions about protocol,
>> so it can be 'trained' to work with any remote, and under very large
>> range of error tolerances.
>>
>> Best regards,
>> Maxim Levitsky
>>
> 
> I think I found the reason behind some of incorrect behavior.
> 
> I see that in-kernel decoding is unhappy about the way I process gaps.
> 
> I do exactly the same I did in lirc driver.
> 
> At the end of keypress, the driver receives series of spaces from
> hardware.
> I accumulate 'em until patience^Wtimeout runs out.
> Then I put hardware in 'idle' mode, and remember current time.
> 
> As soon as I get new pulse, I send a sum of accumulated same and time
> difference to user.
> 
> Therefore every keypress ends with a pulse, and starts with space.
> But in-kernel decoding isn't happy about it, it seems.. at least NEC
> decoder...
> 
> How you think to solve that?
> Fix in-kernel decoders maybe?

Just send whatever you receive from hardware to the decoders. both LIRC and
decoders have already a code to handle the timeouts.

Cheers,
Mauro