Folks, I really want to tell everyone that doing all the mapping from raw codes to keypresses in kernel is wrong. This idea keeps showing up, because many users think that remotes send some universal codes that you can just 'parse' and feed back to input system. Its not the case. There are many protocols, I know that by experimenting with my universal remote. There are many receivers, and all have different accuracy. Most remotes aren't designed to be used with PC, thus user has to invent mapping between buttons and actions. Its is not possible to identify remotes accurately, many remotes send just a 8 bit integer that specifies the 'model' thus many remotes can share it. Some don't send anything. There are some weird remotes that send whole packet of data will all kind of states. Think about it, video capture device is also an input device, a scanner is an input device too, sound card can work as input device too. But we aren't doing any parsing, even we don't support deflating of many proprietary and standard video/image encoding formats. We let userspace do it. Kernel job is to take the information from device and present it to userspace using uniform format, that is kernel does 1:1 translating, but doesn't parse the data. Uniform format doesn't mean kernel always converts to one format, its not like sound card always recording in 32 bit 96000 Khz format, even if underlying device doesn't support that. So, device that decode IR code are presented to userspace as pure input devices. I agree that creating fake raw codes from that is bad. But devices that send raw data pass it to lirc. lirc is well capable to decode it, and its not hard to add auto-detection based on existing configuration drivers, so IR devices will work with absolutely no configuration. All you will have to do is ensure that lirc is installed. Then udev can even start it automatically. Then as soon as you press a key, lirc can scan its config database, and find a config file to use. combine that with a GUI for unknown remotes and you get an awesome usability. Also don't forget that there are pure userspace drivers. They won't have access to in-kernel decoder so they will still have to parse protocols, so will have code duplication, and will still need lirc thus. So why to burden the kernel with protocols, etc.. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html