Kenneth Aafl?y wrote: > On Tuesday 08 March 2005 00:42, Oliver Endriss wrote: > > 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. > > Remote controls are not keyboards, there is no standardization. > > Remote controls are as close to keyboards as it can be any other device, > so why not leverage on that and put any missing pieces into the kernel? Keyboards have standardized layouts, so it's easy to provide keymaps. This is what every linux distribution does. Remote controls are different. There are hundreds of remote controls which require different keymaps. So: > > An user must be able to create a keymap without reading log files. > > Well, this is mostly not possible even with special keyboards..ie you > read the dmesg to tell what key was pressed that did not register > with the kernel, and then use scancode to input info.. That's not user-friendly. It would be easy to write a keymap editor iff we could get raw scancodes from the driver. (Well, could also be done this using sysfs/procfs -> driver-specific and not desirable.) > > Well, I have no problem if the keymap support would be improved. > > Anyway, most problems could be avoided if we would simply fill the gaps > > in the keymap (if the keymap is small enough, of course). > > I'm still convinced that a standard keyboard input device would do.. I never said that it won't do. ;-) All dvb remote control drivers are keyboard input devices. But I don't like the way some things are handled by the input driver. > > The budget-ci driver has a fixed keymap of size 64 (2^6). > > The gaps will cause dead keys if you use a generic RC5 remote control > > or the vendor delivers a new type of remote control. > > It's very easy to fill these gaps, and it would not break anything. > > Which is not uncommon on keyboards not known to the kernel.. I'd like to make things easier for the user. Neither LIRC nor VDR care whether pressing the TV-button creates the correct key event. It's only important to avoid dead keys. > > The input driver supports keymaps with 8/16/32 bit scan codes. > > Unfortunately, these key maps must be contiguous. > > Not a problem for 8 bit keymaps, but memory is wasted if 16/32 bit scan > > codes are being used... > > Are you beeing serious, we're talking bits here? Hm? Maybe should should look into the input/evdev driver. Example: If scan codes are 0..0x1fff (13 bits), you need a 2*8K = 16 KByte keymap for each device. Typically less than 40 entries are really used! What happens if you have 32-bit full-range scan codes? > > I'd really like to improve keymap support but imho the input driver does > > not provide a good infrastructure to do this: > > - no way to read raw scan codes > > There is a utility to output keycodes to the terminal, only I can't remember > what name it got, even with a quick shell test.. You can't read untranslated scan codes from the input driver, because there is no ioctl for that. > > - no way to pass setup information to the driver > > Setup options is passed wia setkeycodes or sysfs. Using sysfs is basically the same as using /proc/av7110_ir for FF cards. It's bad to do this in a driver-specific way. > > - no support for sparse keymaps > > What, please explain.. See example above. Oliver -- -------------------------------------------------------- VDR Remote Plugin available at http://www.escape-edv.de/endriss/vdr/ --------------------------------------------------------
