Re: [PATCH RFC] ir-rc5-decoder: don't wait for the end space to produce a code

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

Em 22-10-2010 23:25, Maxim Levitsky escreveu:
> On Thu, 2010-10-21 at 11:56 -0200, Mauro Carvalho Chehab wrote:
>> Em 21-10-2010 11:46, Jarod Wilson escreveu:
>>> On Oct 20, 2010, at 1:18 PM, Mauro Carvalho Chehab wrote:
>>>
>>>> The RC5 decoding is complete at a BIT_END state. there's no reason
>>>> to wait for the next space to produce a code.
>>>
>>> Well, if I'm reading things correctly here, I think the only true functional difference made to the decoder here was to skip the if
>>> (ev.pulse) break; check in STATE_FINISHED, no? In other words, this looks like it was purely an issue with the receiver data parsing,
>>> which was ending on a pulse instead of a space. I can make this guess in greater confidence having seen another patch somewhere that
>>> implements a different buffer parsing routine for the polaris devices though... ;)
>>
>> This patch doesn't solve the Polaris issue ;)
>>
>> While I made it in the hope that it would fix Polaris (it ended by not solving), I still think it can be kept, as
>> it speeds up a little bit the RC-5 output, by not waiting for the last space.
>>
>> I'll be forwarding soon the polaris decoder fixes patch, and another mceusb patch I did,
>> improving data decode on debug mode.
>>
>>> The mceusb portion of the patch is probably a worthwhile micro-optimization of its ir processing routine though -- 
>>> don't call ir_raw_event_handle if there's no event to handle. Lemme just go ahead and merge that part via my staging tree, 
>>> if you don't mind. (I've got a dozen or so IR patches that have been queueing up, planning on another pull req relatively soon).
>>>
>>
>> Oh! I didn't notice that this went into the patch... for sure it doesn't belong here.
>> Yes, it is just a cleanup for mceusb. Feel free to split it, adding a proper description for it
>> and preserving my SOB.
> 
> No need in this patch.
> My patch resolves the issue genericly by making the driver send the
> timeout message at the end of the data among the current length of the
> space (which will continue to grow).
> 
> Just make mceusb send the timeout sample.


Hmm... now, a RC6(0) remote is also being decoded as a RC5 remote. Could this be due to
your patches?

Not handling the entire state machine could cause troubles with some decoders.

Cheers,
Mauro