On Fri, 2010-05-28 at 00:47 -0400, Jarod Wilson wrote: > So I'm inching closer to a viable mceusb driver submission -- both a > first-gen and a third-gen transceiver are now working perfectly with > multiple different mce remotes. However, that's only when I make sure > the mceusb driver is loaded w/only the rc6 decoder loaded. When > ir-core comes up, it requests all decoders to load, starting with the > nec decoder, followed by the rc5 decoder, then the rc6 decoder and so > on (init_decoders() in ir-raw-event.c). When I call > ir_raw_event_handle, all decoders get run on the ir data buffer, > starting with nec. Well, the nec decoder doesn't like the rc6 data, so > it pukes. The RUN_DECODER macro break's out of the routine when that > happens, and the rc6 decoder never gets a chance to run. (Similarly, > if only ir-nec-decoder has been removed, the rc5 decoder pukes on the > rc6 data, same problem).
Yes, if the system kernel is going to attempt to discriminate between various input singals, it needs to let all its "correlators" run and produce a "confidence" number from each. Then ideally one would take the result with the highest confidence. Right now it looks like all the confidence determinations are boolean (0 or -EINVAL) and there is no chance to deal with the case that two different decoders validly decode something. The first decoder that declares a match "wins" and sends an event. > If I'm thinking clearly, rather than breaking > out of the loop in RUN_DECODER, we really ought to be issuing a > continue to go on to the next decoder, and possibly be accumulating > failures, though I don't know that _sumrc actually matters other than > "greater than zero" (i.e., at least one decoder was successfully able > to decode the signal). If I'm not thinking clearly, a pointer to what > I'm missing would be appreciated. :) You will have to deal with the case that two or more decoders may match and each sends an IR event. (Unless the ir-core already deals with this somehow...) Regards, Andy -- 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
