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 for Android: free password hash cracker in your pocket

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

Message-ID: <87pr6uafdz.fsf@tac.ki.iif.hu>
Date:	Fri, 04 Dec 2009 17:11:04 +0100
From:	Ferenc Wagner <wferi@...f.hu>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Mauro Carvalho Chehab <mchehab@...hat.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

Dmitry Torokhov <dmitry.torokhov@...il.com> writes:

> On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
>> Ferenc Wagner wrote:
>>> Mauro Carvalho Chehab <mchehab@...hat.com> writes:
>> 
>> We should not forget that simple IR's don't have any key to select the address,
>> so the produced codes there will never have KEY_TV/KEY_DVD, etc.
>
> Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select
> media inputs in a device/application. My receiver accepts codes like
> that.

Sorry, my point wasn't the event names, I picked them for their
superficial correspondence to the TV, DVD, SAT etc. buttons found on
multifunction remotes.  Obviously I picked wrong.

I was also wrong to assume that remotes with such buttons are always
multifunction remotes in the sense that they are meant to control
separate devices.  As Mauro pointed out, (some) bundled remotes with
such buttons aren't; thus I wouldn't consider them multifunction at all.
They simply have some extra buttons labelled TV, DVD etc, which probably
shouldn't be mapped to KEY_TV, KEY_DVD etc. (since those events carry
different semantics) but should be mapped to something else.  Or not, if
these buttons change some internal decoder state instead, modifying the
mapping or destination input device of the other keys.

It's just a different scenario, where the kernel could reasonably give
rather different representations to simple applications aiming at
plug&play: letting through the function change events untouched, or
masking and using them internally.

True multifunction devices don't send such events, the TV, DVD etc
buttons on them change their internal state and the scan codes sent by
the other keys, if I understand this correctly.

I'd prefer if these two behaviours could be abstacted from, and the
input layer interface would provide destination selection events +
generic events, or (to be defined) device specific events only in either
case.  Is that possible or even reasonable?
-- 
Thanks,
Feri.

Ps: I'm writing this in the hope to clean up the landscape and possibly
help in choosing the best design.  I'm not at all familiar with IR, and
the above distinction was pretty surprising for me.  Also, I'm just
lurking here, so don't take me too seriously. :)
--
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/