From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]:2521 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756109Ab0G1Skc (ORCPT ); Wed, 28 Jul 2010 14:40:32 -0400 Message-ID: <4C5079AC.9030006@redhat.com> Date: Wed, 28 Jul 2010 15:40:44 -0300 From: Mauro Carvalho Chehab MIME-Version: 1.0 To: Jarod Wilson CC: Jon Smirl , Maxim Levitsky , Jarod Wilson , linux-input , linux-media@vger.kernel.org Subject: Re: Can I expect in-kernel decoding to work out of box? References: <1280298606.6736.15.camel@maxim-laptop> <4C502CE6.80106@redhat.com> <1280327080.9175.58.camel@maxim-laptop> <4C505313.2010904@redhat.com> <4C50720D.5000301@redhat.com> <20100728180516.GG26480@redhat.com> In-Reply-To: <20100728180516.GG26480@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org List-ID: Em 28-07-2010 15:05, Jarod Wilson escreveu: > On Wed, Jul 28, 2010 at 03:08:13PM -0300, Mauro Carvalho Chehab wrote: >> Em 28-07-2010 14:04, Jon Smirl escreveu: >>> On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab >>> wrote: >>>> Em 28-07-2010 11:41, Jon Smirl escreveu: >>>> >>>>> It's possible to build a Linux IR decoder engine that can be loaded >>>>> with the old LIRC config files. >>>> >>>> I think it is a good idea to have a decoder that works with such files anyway. >>> >>> The recorder should use the Linux IR system to record the data. It >>> would confusing to mix the systems. Users need to be really sure that >>> the standard protocol decoders don't understand their protocol before >>> resorting to this. Any one in this situation should post their >>> recorded data so we can check for driver implementation errors. >>> >>> An example: if you use irrecord on Sony remotes lirc always records >>> them in raw mode. The true problem here is that irrecord doesn't >>> understand that Sony remotes mix different flavors of the Sony >>> protocol on a single remote. This leads you to think that the Sony >>> protocol engine is broken when it really isn't. It's the irrecord tool >>> that is broken. The kernel IR system will decode these remotes >>> correctly without resorting to raw mode. >> >> A decoder like that should be a last-resort decoder, only in the >> cases where there's no other option. >> >>>> There are some good reasons for that, as it would allow in-kernel support for >>>> protocols that may have some patent restrictions on a few countries that allow >>>> patents on software. >>> >>> Are there any IR protocols less than 20 (or 17) years old? >> >> Yes. This protocol is brand new: >> https://www.smkusa.com/usa/technologies/qp/ >> >> And several new devices are starting to accept it. > > The US patent appears to have been filed in 1995 and granted in 1997, so > "brand new" is relative. ;) Yes, I saw the patent timestamps too ;) Yet, AFAIK, they're starting to use this protocol on newer IR devices, so, we'll probably see some new devices using it. > > http://www.freepatentsonline.com/5640160.html > > We do have a few more years of being encumbered by it here in the US > though. :( > :( Cheers, Mauro.