Em Fri, 28 Aug 2009 12:50:27 +0200 (CEST)
Patrick Boettcher [off-list ref] escreveu:

Hi Mauro,

On Fri, 28 Aug 2009, Mauro Carvalho Chehab wrote:

quoted

Em Fri, 28 Aug 2009 00:46:28 -0300
Mauro Carvalho Chehab [off-list ref] escreveu:

quoted

So, we need a sort of TODO list for IR changes. A start point (on a random
order) would be something like:

2) Implement a v4l handler for EVIOCGKEYCODE/EVIOCSKEYCODE;
3) use a different arrangement for IR tables to not spend 16 K for IR table,
yet allowing RC5 full table;
4) Use the common IR framework at the dvb drivers with their own iplementation;
5) Allow getkeycode/setkeycode to work with the dvb framework using the new
methods;

Ok, I have a code that handles the above for dvb-usb. Se enclosed. It turned to be
simpler than what I've expected originally ;)

Yeah, this is due to the nature of modularity of dvb-usb. 

Yes, but I was afraid that we would need to use a different struct for IR's.
This feature is already available for years at V4L, but the tables needed to
use scancode as their indexes to use the default handlers (I'm not sure, but
afaik, in the past there weren't ways to override them).

Saying that, all 
drivers which have (re)implemented IR-handling needs to ported as well. Or 
included in dvb-usb :P .

My suggestion is to port the current implementation to ir-common.ko. This
module is not dependent of any other V4L or DVB specifics and has already
some code to handle GPIO polling based and GPIO IRQ based IR's. It contains
some IR tables for IR's that are used also on dvb-usb, like Hauppauge IR
keycodes.

Yet, we will need first to change ir-common.ko, since it is currently using the
tables indexed by a 7bit scancode (due to size constraints, V4L code discards
one RC5 byte), but this is already on our todo list (due to keycode
standardization).

quoted

Tested with kernel 2.6.30.3 and a dibcom device.

While this patch works fine, for now, it is just a proof of concept, since there are a few
details to be decided/solved for a version 2, as described bellow.

This is the answer to the question I had several times in the past years.

Very good job. It will solve the memory waste in the driver for 
key-tables filled up with keys for different remotes where the user of 
one board only has one. The code will also be smaller and easier to read.

This also allows the user to use any remote with any (sensitive) 
ir-sensor in a USB device.

True.

Is there a feature in 'input' which allows to request a file (like 
request_firmware)? This would be ideal for a transition from 
in-kernel-keymaps to user-space-keymap-loading: By default it would 
request the file corresponding to the remote delivered with the device.

Is that possible somehow?

There's nothing that I'm aware of, but I suspect that it shouldn't be hard to do it
via udev. 

We'll need to do some work there, in order to be sure that each V4L and DVB
device will have their own unique IR board ID's. We may then do an application
based on  v4l2-apps/util/keytable that will use the IR board ID to 
dynamically load the keytable, with a default config of loading the board's own
IR, but allowing the user to replace it by a custom one.

Currently, the Makefile at v4l2-apps/util creates a directory (keycodes) that
contains lots of IR tables. It does it by parsing the existing IR tables at V4L
side. After having all tables looking the same, it won't be hard to change it
to parse all MCE tables, creating an updated repository of the existing
scancode/keycode association.



Cheers,
Mauro