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@xxxxxxx WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/
