[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B16D26E.9010200@redhat.com>
Date: Wed, 02 Dec 2009 18:47:42 -0200
From: Mauro Carvalho Chehab <mchehab@...hat.com>
To: Jon Smirl <jonsmirl@...il.com>
CC: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Devin Heitmueller <dheitmueller@...nellabs.com>,
Maxim Levitsky <maximlevitsky@...il.com>, awalls@...ix.net,
j@...nau.net, jarod@...hat.com, jarod@...sonet.com, khc@...waw.pl,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, lirc-list@...ts.sourceforge.net,
superm1@...ntu.com, Christoph Bartelmus <lirc@...telmus.de>
Subject: Re: [RFC v2] Another approach to IR
Jon Smirl wrote:
> IR devices transmit vendor/device/command triplets. They are easy to
> tell apart and create an evdev device corresponding to each
> vendor/device pair or something else along those lines.
What they transmit depend on the used protocol. With NEC and RC5 (currently, the
most common protocols), they transmit only address (TV, VCR, SAT) and command.
If you have two IR's that not fully follow RC5 standard, they may use distinct
addresses. So, if you're lucky enough, you'll be able to guess the IR vendor,
based on the 8 bit address code.
I think that you can get the vendor only with RC6 IR's on some modes.
In the case of RC6, as pointed by Andy, there are some patents envolved,
meaning that we probably will need to decode it on userspace, except if
someone can get the proper patent rights for its used on Linux.
Cheers,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists