Hi Mauro, on 04 Dec 09 at 12:33, Mauro Carvalho Chehab wrote: > Christoph Bartelmus wrote: >>>> Consider passing the decoded data through lirc_dev. [...] >> Consider cases like this: >> http://lirc.sourceforge.net/remotes/lg/6711A20015N >> >> This is an air-conditioner remote. >> The entries that you see in this config file are not really separate >> buttons. Instead the remote just sends the current settings for e.g. >> temperature encoded in the protocol when you press some up/down key. You >> really don't want to map all possible temperature settings to KEY_* >> events. For such cases it would be nice to have access at the raw scan >> codes from user space to do interpretation of the data. >> The default would still be to pass the data to the input layer, but it >> won't hurt to have the possibility to access the raw data somehow. > Interesting. IMHO, the better would be to add an evdev ioctl to return the > scancode for such cases, instead of returning the keycode. That means you would have to set up a pseudo keymap, so that you can get the key event which you could than react on with a ioctl. Or are you generating KEY_UNKNOWN for every scancode that is not mapped? What if different scan codes are mapped to the same key event? How do you retrieve the scan code for the key event? I don't think it can work this way. Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
