Re: [RFC v2] Another approach to IR

[Ferenc Wagner <wferi@niif.hu>]

Mauro Carvalho Chehab <mchehab@redhat.com> writes:

> Dmitry Torokhov wrote:
>
>>>>> On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:
>>>>>
>>>>>> Now I understand that if 2 remotes send completely identical
>>>>>> signals we won't be able to separete them, but in cases when we
>>>>>> can I think we should.
>>
>> They are the same key events (Lets's say KEY_PLAY) but one is
>> supposed to affect CD player while another DVD player
>> application. Evdev will not be able to distinguish them but if we had
>> 2 separate devices then applications could read from the one thet
>> user assigned to them.
>
> This is clear, but the point is that the two distinguish scancodes can
> (and, in practice, will) be generated by the same IR. For example, my
> Satellite IR produces two different sets of codes. if you press <SAT>,
> all keys you press after that will have the "sat" address. If you
> press <TV>, they'll get a different address.

The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
by any remote (ok, I'm stretching it a bit).  Instead, a multifunction
remote (or two distinct remotes) would send different scan codes[1],
which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
Btw. the former is already defined, besides the generic KEY_PLAY.

Even if all this worked, user space would need integration with
hal/devicekit to open the new input devices appearing on the fly (if
it's initiated by the arrival of a scan code belonging to some new
protocol), and also be able to decide whether the new event source is
for it or not.

Given that commodity home appliances manage not to be confused by
multiple or multifunction remotes, decent software should be able to do
so as well.

[1] scan codes in the broadest possible sense, containing vendor,
address and whatever, and only treating the case which is possible to
handle in principle.
-- 
Regards,
Feri.