Re: Can I expect in-kernel decoding to work out of box?

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Em 28-07-2010 11:53, Jon Smirl escreveu:
> On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls <awalls@md.metrocast.net> 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