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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
