Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

[Jon Smirl <jonsmirl@gmail.com>]

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-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html