On Wed, 2010-07-28 at 13:35 -0400, Jon Smirl wrote: > On Wed, Jul 28, 2010 at 1:02 PM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> wrote: > > On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote: > >> Em 28-07-2010 11:53, Jon Smirl escreveu: > >> > On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> wrote: > >> >> On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote: > > > >> > I recommend that all decoders initially follow the strict protocol > >> > rules. That will let us find bugs like this one in the ENE driver. > >> > >> Agreed. > > > > Well... > > > > I'd possibly make an exception for the protocols that have long-mark > > leaders. The actual long mark measurement can be far off from the > > protocol's specification and needs a larger tolerance (IMO). > > > > Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a > > protocol element that is 8 to 16 protocol time units long, doesn't make > > too much sense to me. If the remote has the basic protocol time unit > > off from our expectation, the error will likely be amplified in a long > > protocol elements and very much off our expectation. > > Do you have a better way to differentiate JVC and NEC protocols? They > are pretty similar except for the timings. Yes: Invoke the 80/20 rule and don't try. Enable NEC and disable JVC by default. Let the users know so as to properly manage user expectations. (Maxim's original question was about expectation.) When the user knows NEC isn't working, or he suspects JVC may work, he can bind that protocol to the particular IR receiver. Trying to solve the discrimination problem with blindly parallel decoding all the possible protocols is a big waste of effort IMO: a. Many remotes are sloppy and out of spec, and get worse with weak batteries. b. The IR receiver driver knows what remotes possibly came bundled with the hardware. (For the case of the MCE USB, it's almost always an RC-6 6A remote.) c. The user can tell the kernel about his remote unambiguously. There's no burning need to wear a blindfold, AFAICT, so let's not. Why bother to solve a hard problem (discrimination of protocols from out of spec remotes), when it raises the error rate of solving the simple one (properly decoding a single protocol)? Doing many things poorly is worse than doing one thing well. Non-adaptive protocol discovery (i.e. blind parallel decoding) should not be the default if it leads to problems or inflated expectations for the user. > What happened in this case > was that the first signals matched the NEC protocol. Then we shifted > to bits that matched JVC protocol. > > The NEC bits are 9000/8400 = 7% longer. If we allow more than a 3.5% > error in the initial bit you can't separate the protocols. > > In general the decoders are pretty lax and the closest to the correct > one with decode the stream. The 50% rule only comes into play between > two very similar protocols. > > One solution would be to implement NEC/JVC in the same engine. Then > apply the NEC consistency checks. If the consistency check pass > present the event on the NEC interface. And then always present the > event on the JVC interface. It's just too simple to have the user: a. Try NEC b. Try JVC c. Make a judgment and stick with the one he perceives works. To have reliable discrimination in the general case between two protocols, given the variables out of our control (i.e. the remote control implementation) would require some sort of data collection and adaptive algorithm to go on inside the kernel. I don't think you can get reliable discrimination in one key press. Maybe by looking at the key press and the repeats together might up the probability of correct discrimination (that's one criterion you examined to make a determination in your earlier email). Regards, Andy -- 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
