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: <alpine.LRH.2.00.0912011833070.11226@pub6.ifh.de>
Date:	Tue, 1 Dec 2009 18:35:23 +0100 (CET)
From:	Patrick Boettcher <pboettcher@...nellabs.com>
To:	Devin Heitmueller <dheitmueller@...nellabs.com>
cc:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Jon Smirl <jonsmirl@...il.com>,
	Maxim Levitsky <maximlevitsky@...il.com>, awalls@...ix.net,
	dmitry.torokhov@...il.com, j@...nau.net, jarod@...hat.com,
	jarod@...sonet.com, 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

Hi,
On Tue, 1 Dec 2009, Devin Heitmueller wrote:

> On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
> <mchehab@...hat.com> wrote:
>> Just taking an example from the dibcom0700 driver (as the same driver
>> supports several different RC5 and NEC codes at the same time),
>> the kernel table has several keycodes added there, all working
>> at the same time. Providing that the scancodes won't overlap, you can
>> map two different scancodes (from different IR's) to return the same
>> keycode (table is not complete - I just got a few common keycodes):
>
> Mauro,
>
> Just to be clear, the dib0700 does not actually support receiving RC5
> or NEC codes at the same time.  You have to tell the chip which mode
> to operate in, via a REQUEST_SET_RC to the firmware (see
> dib0700_core.c:405).  The em28xx works the same way (you have to tell
> it what type of IR format to receive).
>
> The fact that the driver currently uses the same lookup table for both
> types of remote controls however, was perhaps not the best design
> choice.  It really should be separated out, and merged with the
> regular ir-functions.c.  I just never got around to it.

I did not follow all the discussion, still I have a comment:

I will soon work on a device where it is the driver who is doing the 
decoding of the IR-frames. It is (maybe, I'm still missing some pieces to 
be sure) possible to receive different protocols at the same time with 
this hardware.

--

Patrick 
http://www.kernellabs.com/
--
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/