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: <4B155288.1060509@redhat.com>
Date:	Tue, 01 Dec 2009 15:29:44 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Devin Heitmueller <dheitmueller@...nellabs.com>
CC:	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

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).

Yes, I know. I have a dib0700-based device that came with a NEC table, and
I had to fix the driver to work with NEC on newer (1.20) firmwares and add the
corresponding table for my NEC IR. Still I prefer to use this device with a
RC5 IR from another manufacturer ;)

Yet, the same table works on my device with the shipped IR and with some
other RC5 IR's I have. Due to the lack of an API to select the IR standard,
I need to reload the module, passing a different modprobe parameter, to
set it to either mode.

> 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'm not sure if splitting the table on two would be the better way.

For sure we need to add an EVIOSETPROTO ioctl to allow the driver 
to change the protocol in runtime.

If we'll keep using the same table, all an userspace app need is to say what's
the desired IR mode. On the other hand, it should be easy for the application
to also replace the table when a different protocol is selected.

The point that I want to bold is that it is possible to use one big table to
support several different IR's at the same time. This may be a good solution for
devices that were shipped with more than one different IR models. It may also
be a good solution to avoid having a large number of keymaps, as we may consolidate
commonly used IR's on an unique table (or on a few groups of tables).

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/