Stefan Richter wrote: > Krzysztof Halasa wrote: >> Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> writes: >> >>> Event input has the advantage that the keystrokes will provide an unique >>> representation that is independent of the device. >> This can hardly work as the only means, the remotes have different keys, >> the user almost always has to provide customized key<>function mapping. > > Modern input drivers in the mainline kernel have a scancode-to-keycode > translation table (or equivalent) which can be overwritten by userspace. > The mechanism to do that is the EVIOCSKEYCODE ioctl. This mechanism is already used by all V4L drivers and several DVB drivers. > (This is no recommendation for lirc. I have no idea whether a > pulse/space -> scancode -> keycode translation would be practical there.) pulse/space -> scancode translation is already done by several existing drivers. For example, there are several bttv and saa7134 devices that polls (or receive IRQ interrupts) to detect pulses (and the absense of them) in order to create a pulse/space code. The conversion from pulse/space to scancode is done inside the driver, with the help of some generic routines and based on the protocol specifications. The conversion from the scancode to a keycode is done based on in-kernel keycode tables that can be changed from userspace with EVIOCSKEYCODE ioctl. I can't see any technical reason why not doing the same for the lirc drivers, except for one issue: Those devices where the decoding is done by software can support any IR protocols. So, it is possible to buy a device with a NEC IR, and use a RC5 IR to control it. However, currently, there's no way to inform the kernel to use a different algorithm to translate the kernel. This can be solved by adding a few ioctls to enumerate the supported protocols and to select the one(s) that will be handled by the kernel driver. Cheers, Mauro -- 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
