On Fri, 2010-10-22 at 23:39 -0200, Mauro Carvalho Chehab wrote: > 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? Very unlikely. Probably the remote is really RC5 RC5 and RC6 just differ too much. And besides mceusb doesn't even send the timeouts yet. Still you could revert and see if it helps. The only patch that has any potential of breaking anything is the '[PATCH 1/3] IR: extend ir_raw_event and do refactoring' Note that I tried going the way this patch does. And it really doesn't work. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
