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]

Date:	Wed, 2 Dec 2009 13:12:18 -0800 (PST)
From:	Trent Piepho <xyzzy@...akeasy.org>
To:	Jarod Wilson <jarod@...sonet.com>
cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jarod Wilson <jarod@...hat.com>,
	Jon Smirl <jonsmirl@...il.com>,
	Mauro Carvalho Chehab <mchehab@...hat.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

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.  You don't want your computer turning off when you push
the power button on the DVD player's remote, do you?

Each host connected to a network interface doesn't get its own device.
--
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/