linux-kernel - Re: [RFC v2] Another approach to IR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87tyw8ujsr.fsf@tac.ki.iif.hu>
Date:	Thu, 03 Dec 2009 17:03:16 +0100
From:	Ferenc Wagner <wferi@...f.hu>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jarod Wilson <jarod@...sonet.com>,
	Jarod Wilson <jarod@...hat.com>,
	Jon Smirl <jonsmirl@...il.com>,
	Devin Heitmueller <dheitmueller@...nellabs.com>,
	Maxim Levitsky <maximlevitsky@...il.com>, awalls@...ix.net,
	j@...nau.net, 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

Mauro Carvalho Chehab <mchehab@...hat.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.
--
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/