Re: [RFC] Infrared Keycode standardization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Em Fri, 28 Aug 2009 12:50:27 +0200 (CEST)
Patrick Boettcher <pboettcher@xxxxxxxxxxxxxx> escreveu:

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

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

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

[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux