On Tuesday 08 March 2005 03:07, Oliver Endriss wrote: > Kenneth Aafl?y wrote: > > 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. Find a complete layout for my Logitech LX501... > Remote controls are different. There are hundreds of remote controls > which require different keymaps. So: Nope, but... > > > 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.) What are you talking about? The user get the raw scancode from the utility mentioned elsewhere, and then inputs what key it should emit. If someone would write a GUI for this it would be great.. > > > 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. How so? > > > 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. No stuff is easy in linux as viewed from the user side of the kernel.. it's the job of the distribution to make this experience smooth! > > > 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. Maybe... > 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? What if you have a full x86 keyboard, some 106*3 (or so), does that do justice? So you are talking about the internals of how scancodes are stored as opposed to how their size is? Now that would be a topic for the lkml... > > > 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. Hmm, but the kernel reports those via it's stderr, no? If you want another reporting mechanism, I'd suggest lkml. > > > - 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. Actually not, as sysfs is usually per device, and procfs was per instance. > > > - no support for sparse keymaps > > What, please explain.. > See example above. See above.. Kenneth
