general remote control mechanism (was: Re: [linux-dvb] Hauppauge
Nova-T PCI on Fedora Core 3)
kraxel at bytesex.org
Tue Mar 8 10:24:26 CET 2005
Oliver Endriss <o.endriss at gmx.de> writes:
> Patrick Boettcher wrote:
> > On Mon, 7 Mar 2005, Oliver Endriss wrote:
> > > In kernel 2.6 there are 2 ioctls to manipulate keymaps
> > > - EVIOCGKEYCODE
> > > - EVIOCSKEYCODE
> > > Fine, they could be used to implement generic keymaps. But...
> > I think this is what Gerd is using in his
> > http://dl.bytesex.org/cvs-snapshots/input-<version>.tar.gz
> > keymap-upload-tool. (He just pointed that out in another mail)
> Yes, exactly.
> Unfortunately, there is no user-friendly way to *create* a keymap.
Well, some helper app could help with that, just load some dummy
mapping to have a unique ID for every key, then let the user press and
describe them ...
> Remote controls are not keyboards, there is no standardization.
Well, sort of, at least for some, there are standard mappings for rc5
for example. Doesn't work perfect, but usually it is a good start.
My intention is that the remotes shipped with the cards "just work"
out of the box by driver-provides maps. Not allways that easy as for
example Hauppauge ships at least three different remotes, but neverthe
less that is the plan. So ideally the user has to go through the
process of creating a custom map only when using some 3rd party
> Anyway, most problems could be avoided if we would simply fill the gaps
> in the keymap (if the keymap is small enough, of course).
128 keys at the moment for everything which uses ir-common.[ch]
> RC5 uses 5 bits for the device address and 6 bits for data.
My drivers ignore the device address at the moment and only use the 6
data bits. Not perfect, but helps to keep the keymap small (big
sparse ones are a problem as you've noted ...) and doesn't hurt as
long as you use one remote only.
#define printk(args...) fprintf(stderr, ## args)
More information about the linux-dvb