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 15:40:44 -0300 Message-ID: <4C5079AC.9030006@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100728180516.GG26480@redhat.com> Sender: linux-media-owner@vger.kernel.org To: Jarod Wilson Cc: Jon Smirl , Maxim Levitsky , Jarod Wilson , linux-input , linux-media@vger.kernel.org List-Id: linux-input@vger.kernel.org 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.