From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mauro Carvalho Chehab Subject: Re: Can I expect in-kernel decoding to work out of box? Date: Wed, 28 Jul 2010 12:42:19 -0300 Message-ID: <4C504FDB.4070400@redhat.com> References: <1280269990.21278.15.camel@maxim-laptop> <1280273550.32216.4.camel@maxim-laptop> <1280298606.6736.15.camel@maxim-laptop> <4C502CE6.80106@redhat.com> <1280327929.11072.24.camel@morgan.silverblock.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com ([209.132.183.28]:23295 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755478Ab0G1PmK (ORCPT ); Wed, 28 Jul 2010 11:42:10 -0400 In-Reply-To: Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Jon Smirl Cc: Andy Walls , Maxim Levitsky , Jarod Wilson , linux-input , linux-media@vger.kernel.org Em 28-07-2010 11:53, Jon Smirl escreveu: > On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls 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