Johannes Stezenbach wrote: > Patrick Boettcher wrote: > > On Sun, 6 Mar 2005, Lauri Tischler wrote: > > >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). > > We have dvb-apps/util/av7110_loadkeys, but it makes no sense to > replicate this for each card. I remember there was some discussion about > IR input and configurable keymaps on lkml a long time ago, but no one came > forward and implemented something. > Gerd Knorr wrote drivers/media/common/ir-common.c, which might > be reusable/extendable for DVB. > > > Will lirc ever be inside the stock kernel? Is lirc an option for such > > things? > > There is a difference between traditional LIRC drivers, which > output raw samples from an IR receiver to be interpreted > by userspace software (which is very flexible), and the > IR drivers we have for DVB, which output decoded rc5 (or similar) codes. > > IMHO it makes sense to feed rc5 events to the linux-input > system via a keymap. We should either have some generic module > to allow user-settable keymaps, or it could be implemented > in userspace as a daemon which reads from /dev/input/eventX > (using EVIOCGRAB), does the key mapping and feeds back > to /dev/input/uevent. I don't know if there's already > some software which does this, or if the lirc folks > are interested in this. (I remember we had a similar discussion some time ago.) In kernel 2.6 there are 2 ioctls to manipulate keymaps - EVIOCGKEYCODE - EVIOCSKEYCODE Fine, they could be used to implement generic keymaps. But... Unfortunately this interface isn't designed very well. - There is _no_ way to read _untranslated_ keycodes from the driver. How should someone write something like a keymap editor or implement a good key learning procedure without that? (You will never know whether the user has pressed a key or not.) - You cannot pass additional configuration parameters to the driver. The av7110 driver requires RC5/RCMM selection and address information. So we cannot drop the /proc interface anyway. Most applications do some key mapping on their own. Why don't we simply fill all holes in the keymaps of the drivers with some unique codes? This would avoid dead keys which are the main problem right know. Oliver -- -------------------------------------------------------- VDR Remote Plugin available at http://www.escape-edv.de/endriss/vdr/ --------------------------------------------------------
