Messages in this thread | | | Date | Tue, 8 Dec 2009 08:47:45 -0500 | Subject | Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure | From | Jon Smirl <> |
| |
On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab <mchehab@redhat.com> wrote: > Andy Walls wrote: >> On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: >>> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: >> >>>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the >>>> end of the month. >>>> >>>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with >>>> a common set of parameters, so I may be able to set up the decoders to >>>> handle decoding from two different remote types at once. The HVR boards >>>> can ship with either type of remote AFAIK. >>>> >>>> I wonder if I can flip the keytables on the fly or if I have to create >>>> two different input devices? >>>> >>> Can you distinguish between the 2 remotes (not receivers)? >> >> Yes. RC-6 and RC-5 are different enough to distinguish between the two. >> (Honestly I could pile on more protocols that have similar pulse time >> periods, but that's complexity for no good reason and I don't know of a >> vendor that bundles 3 types of remotes per TV card.) > > You'll be distinguishing the protocol, not the remote. If I understood > Dmitry's question, he is asking if you can distinguish between two different > remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 > and another RC-6.
RC-5 and RC-6 both contain an address field. My opinion is that different addresses represent different devices and in general they should appear on an input devices per address.
However, I prefer a different scheme for splitting the signals apart. Load separate maps containing scancodes for each address. When the IR signals come in they are matched against the maps and a keycode is generated when a match is found. Now there is no need to distinguish between the remotes. It doesn't matter which remote generated the signal.
scancode RC5/12/1 - protocol, address, command tuplet. Map this to KP_1 on interface 1. scancode RC5/7/1 - protocol, address, command tuplet. Map this to KP_1 on interface 2.
Using the maps to split the commands out also fixes the problem with Sony remotes which use multiple protocols to control a single device. scancode Sony12/12/1 - protocol, address, command tuplet. Map this to power_on on interface 1. scancode Sony15/12/1 - protocol, address, command tuplet. Map this to KP_1 on interface 1.
> >>> Like I said, >>> I think the preferred way is to represent every remote that can be >>> distinguished from each other as a separate input device. >> >> OK. With RC-5, NEC, and RC-6 at least there is also an address or >> system byte or word to distingish different remotes. However creating >> multiple input devices on the fly for detected remotes would be madness >> - especially with a decoding error in the address bits. >> >> Any one vendor usually picks one address for their bundled remote. >> Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT. > > The address field on RC-5 protocol is not meant to distinguish different > vendors, but different "applications". It identifies that a code should > be sent to a TV or a VCR, or a DVD or a SAT. > > In the case of bundled IR's, some vendors like Hauppauge opted to use a > reserved address to avoid conflicts with other equipments. It happens that > vendor's "reserved address" can be different between two different vendors, > but is just an educated guess to say that an address equal to 0x1e is Hauppauge. > > Cheers, > Mauro. > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
-- Jon Smirl jonsmirl@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |