general remote control mechanism (was: Re: [linux-dvb] Hauppauge Nova-T PCI on Fedora Core 3)

[Patrick Boettcher]

On Sun, 6 Mar 2005, Lauri Tischler wrote:

>> The codes for the remote for the card with both Antenna In and out are not 
>> defined in ir-common.c. "tail -f /var/log/message" while pressing the 
>> remote buttons and you will see the codes and match them against buttons.
>> #if 0 /* FIXME */
>>         [ 0x0a ] = KEY_RESERVED,        // 1/2/3 digits (japan: 10)
>>         [ 0x0e ] = KEY_RESERVED,        // P.P. (personal preference)
>>         [ 0x14 ] = KEY_RESERVED,        // colour saturation +
>>         [ 0x15 ] = KEY_RESERVED,        // colour saturation -
>>         [ 0x16 ] = KEY_RESERVED,        // bass +
>> etc., etc.
>
> Wouldn't it be much easier to have separate tables for each remote
> and then be able select at runtime which remote to use.
> Now there is no usefull remote at all, unless you go and hack
> the kernel.

Yeah, that would be great. Maybe the code-tables can be passed via 
/proc-interface to the driver. dvb-apps then could provide a learning 
tool, which generates the tables.

The dibusb-driver has its own remote-input-stuff, the cingeryT2.c does 
exactly the same, but both don't use dynamic key-assignments.

Maybe there should something like a generic rc library/module for the 
dvb-stuff (or even at a higher layer inside the kernel).

It should be able to handle different remote-control-protocols (ie. 
different rc-key-to-input-event-tables-formats, I know of NEC and a 
Hauppauge specific one (used in NOVA-T USB2), I assume there are more).

Will lirc ever be inside the stock kernel? Is lirc an option for such 
things?

regards,
Patrick.

--
   Mail: patrick.boettcher at desy.de
   WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/