Hi Mauro,
On Fri, 28 Aug 2009, Mauro Carvalho Chehab wrote:
Em Fri, 28 Aug 2009 00:46:28 -0300
Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> escreveu:
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. Saying that, all
drivers which have (re)implemented IR-handling needs to ported as well. Or
included in dvb-usb :P .
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.
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?
Patrick.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
