Andy, Em 28-07-2010 15:18, Andy Walls escreveu: > 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. At the room where my computers is located, I have two wide fluorescent lamps each with 20W. If I don't hide the IR sensors bellow my desk, those lamps are enough to generate random flickers at the sensors. With the more relaxed driver we used to have at saa7134, it ended by producing random scancodes, or, even worse, random repeat codes. So, lots of false-positive events. It is a way worse to have false-positive than having a false-negative events. So, I don't think it is a good idea to use a "relaxed" mode by default. > 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.) We should discuss a little bit about RC subsystem evolution during LPC/2010, but, from my point of view, we should soon deprecate the in-kernel keymap tables on some new kernel version, using, instead, the ir-keycode application to dynamically load the keycode tables via UDEV. Of course, after some time, we may end by removing all those tables from the kernel. So, assuming that we follow this patch, what we'll have for a newer device is: For most devices, the keymap configuration table (rc_maps.cfg) will associate all known devices with their corresponding keytable (we still need to generate a default rc_maps.cfg that corresponds to the current in-kernel mapping, but this is trivial). As ir-keytable disables all protocols but the one(s) needed by a given device, in practice, if the scancode table specifies a NEC keymap table, JVC will be disabled. If the table is for JVC, NEC will be disabled. So, this already happens in a practical scenario, as all decoders will be enabled only before loading a keymap (or if the user explicitly enable the other decoders). So, the device will be in some sort of "training" mode, e. g. it will try every possible decoder, and will be generating the scancodes for some userspace application that will be learning the keycodes and creating a keymap table. IMO, we should have a way to tell the RC and/or the decoding subsystem to work on a "relaxed" mode only when the user (or the userspace app) detects that there's something wrong with that device. > 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). Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
