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: >> Is JVC enabled by default? I recall analyzing that it could generate >> false positives on NEC codes. > > Hopefully the engines should differentiate the two. If the signal is > really messed up it may trigger a response from both engines. That > shouldn't be fatal at the higher layers, the wrong protocol would just > be ignored. By default, both decoders are enabled, but if you're using the ir-keycode userspace program at udev, it will disable all protocols but the ones associated with the RC keytable loaded for that specific device. Even if both JVC and NEC decoders generate scancodes, it is very unlikely that the scancode generated by the wrong decoder would produce a valid scancode at the RC keycode space. > 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. > After we get everything possible working under the strict rules we can > loosen then up to allow out of spec devices. We might even end up with > an IR-quirk driver that supports broken remotes. I think that the better is to add some parameters, via sysfs, to relax the rules at the current decoders, if needed. Cheers, Mauro -- 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
