Oliver Endriss <o.endriss@xxxxxx> 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 remote. > 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] > Example: > 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. Gerd -- #define printk(args...) fprintf(stderr, ## args)
