Vojtech Pavlik <[EMAIL PROTECTED]> writes: > > 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).
writing keymaps works too. Been there, done that while hacking IR remote support via input layer for bttv + saa7134 ... > I'm considering to add a new 'raw' event type for this. I'd like to see that too. > > We need these if we > > want to implement a keymap learning mode or a keymap editor. > > Maybe we have to add this sub-function to the low-level interface, too. > > With the current implementation you have to build keymaps by reading > > debug messages and putting everything together manually. :-( You might want to check out http://bytesex.org/snapshot/input-<date>.tar.gz, that are a few input layer userspace tools (print device info, dumb events, read/write keymaps, ...) I wrote for debugging while hacking the IR support into the bttv + saa7134 drivers. Driver snapshots with IR support available from the snapshot directory too, 2.6.x kernel patches are at bytesex.org/patches/ There are a number of buttons where are no good KEY_* defines for yet (color/contrast/hue, bass/trable/balance, ...) btw. > > The device type may be identified using existing ioctls: > > EVIOCGNAME, EVIOCGPHYS. Is this sufficient? Should be IMHO, I've named them sprintf("pci-%s/input0",pci_name(dev)), that should be unique. Gerd -- You have a new virus in /var/mail/kraxel -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
