On Monday 13 October 2003 12:07, Vojtech Pavlik wrote: > On Mon, Oct 13, 2003 at 05:41:12AM +0200, Oliver Endriss wrote: > > > Basically we need 2 pass-through ioctls: > > - set low level configuration > > - get low level configuration > > I'm not really keen on passing ioctl()s to drivers, but if there is no > other way around, then well ...
Well, we need a clean interface to pass some remote-specific parameters to the low-level driver. Until now this is done using /proc/av7110_ir. But this is just a hack. ;-) > > Each of these ioctls could have several sub-types: > > - access config flags (for example: signal inversion) > > - access keymap (raw addr/code <-> key code mapping) > > - ... > > > > It should be possible to read the current keymap from the device. > > This way one could write something like a keymap editor, or > > add another remote control to a loaded keymap. > > Well, it is currently possible to read a keymap from a keyboard via the > event interface. It doesn't efficiently handle sparse keycode tables, > though, like the remote seems to be using (address + code). Ok, this is a new feature in kernel 2.6. (I checked 2.4 sources only.) Typically, a remote control has less that 50 keys, so it would have been better to read/write keycodes using a low-level driver function and move the implementation (array or list) into the driver. For a reasonable implementation, we need 13-bits or more for scancodes (5 bits address + 8 bits data). We have to select keycode size 16 bits. So we need 8K x 2 = 16Kbyte for the keymap, while 100 bytes would have been sufficient. No problem right now, but what if we need 16/24/32 bit scancodes? > > Another feature which is really missing in the event device stuff is a > > interface to read *raw* keycodes from the device. > > Indeed. That's because the abstraction is placed in the level of defined > keycodes. Since the raw codes are device specific, they should be > contained in the drivers as much as possible. However, I do see that > keymap editors will need the access to these. > > At the moment it's possible to load some kind of 1:1 mapping keytable > and then look at the keycodes, and then look at what keycodes are > coming. This again doesn't handle sparse tables very well (number of > scancodes >> number of keycodes). Unfortunately, keycodes are currently limited to 9 bits (KEY_MAX). Therefore this approach does not work. :-( Currently I'm using some tricks to work around the problem, but that's causing trouble again... > I'm considering to add a new 'raw' event type for this. This would be great! Oliver -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
