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: <4B16DEC3.2070105@redhat.com>
Date:	Wed, 02 Dec 2009 19:40:19 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Jarod Wilson <jarod@...sonet.com>
CC:	Trent Piepho <xyzzy@...akeasy.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.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

Jarod Wilson wrote:
> On Dec 2, 2009, at 4:12 PM, Trent Piepho wrote:
> 
>> On Wed, 2 Dec 2009, Jarod Wilson wrote:
>>>>> My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which "device" some random IR input is actually coming from.
>>>>>
>>>> Heh, right back at ya ;) The fact that you need to do some more work
>>>> to separate 2 physical devices does not mean it should not be done.
>>> No, but it means added complexity inside the kernel. I'm questioning whether the added complexity is worth it, when I doubt the vast majority of users would take advantage of it, and it can already be done in userspace. Although... Damn. The userspace approach would only work if the device were passing raw IR to userspace, so in the in-kernel decoding case, yeah, I guess you'd need separate input devices for each remote to use them independently. Meh. Doubt I'd ever use it, but I guess I'll concede that it makes some sense to do the extra work.
>> You just need to send a tuple that contrains the keycode plus some kind of
>> id for the remote it came from.  That's what I did for lirc, it decodes the
>> sparc/mark into a remote id and key code tuple.  It's certainly a common
>> thing to want.  Anyone who has existing remotes and components that use
>> them would want it.
> 
> What for, exactly?
> 
>> You don't want your computer turning off when you push
>> the power button on the DVD player's remote, do you?
> 
> No, I don't.

In this specific case, IMO, the default keytables should map the power button to KEY_POWER2.
> 
> Perhaps we should clarify something here. Are we intending to auto-create 
> a new input device for every IR command set we see arrive at the IR receiver? 
> I've been assuming we're not going to willy-nilly just auto-create a new device
> for every IR signal we happen to catch passing by. The receiver should only 
> be passing along input events for the codeset/remote I've told it to listen
> for (which by default, is the codes for the receiver's bundled remote).

Yes, but several bundled IR's have a power button. By default, it doesn't make sense
to use it to turn the machine off, so KEY_POWER2 is a good option.

> Otherwise, yeah, I'm going to wind up with my htpc powering off when
> I hit the button on my harmony remote that is supposed to turn off my tv and amp.

Cheers,
Mauro.
--
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/