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

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Jon Smirl wrote:
> On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Jon Smirl wrote:
>>> 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.
>> The same IR can produce two different addresses. The IR bundled with my satellite
>> STB produces two different codes, depending if you previously pressed <TV> or <SAT>
>> key (in fact, I think it can even produce different protocols for TV, as it can
>> be configured to work with different TV sets).
> 
> You have a multi-function remote.

Yes.

> That's why those keys don't send codes. When writing code you should
> think of this remote as being two indpendent virtual remotes, not a
> single one.

Not really. I may think on it as a single device and use the two groups
of functions to control two aspects at the same application.

For example, I may map the <TV> group on kaffeine for DVB reception and the
<SAT> group for DVD (well, probably, in this case, I'll use an IR with
<TV> and <DVD> keys, instead ;) ).

> By using maps containing the two different addresses for <TV> and
> <SAT> you can split these commands onto two different evdev devices.

True. I can do it, but I can opt to have both mapped as one evdev device as well.
This will basically depend on how I want to mount my environment.
 
> This model is complicated by the fact that some remotes that look like
> multi-function remotes aren't really multifunction. The remote bundled
> with the MS MCE receiver is one. That remote is a single function
> device even though it has function buttons for TV, Music, Pictures,
> etc.

It is very common to have such remotes bundled with multimedia devices.

An unsolved question on my mind is how should we map such IR's? Should we
provide a way for them to emulate a multifunction IR (for example, after pressing
TV key, subsequent keystrokes would be directed to the TV evdev device?), or
should we let this up to some userspace app to handle this case?
 
Cheers,
Mauro.