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. Thanks, 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
