On Mon, Aug 20, 2012 at 6:02 PM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > So, IMO, it makes sense to have a "high end" API that accepts > writing keystrokes like above, working with both "raw drivers" > using some kernel IR protocol encoders, and with devices that can > accept "processed" keystrokes, like HDMI CEC. It might also make sense to have a third mode for devices that support high level protocols such as RC5/NEC but you want to leverage the very large existing LIRC database of remote controls. The device would advertise all the modes it supports (RC5/NEC/RC6/whatever), and from there it can accept the actual RC codes instead of a raw waveform. I recognize that this is case that falls in between the two models proposed, but there are devices that fall into this category. The alternative for those devices would be for LIRC to convert the RC5 code into a raw waveform, send the raw waveform to the kernel, and then the driver convert it back into a code, which would be quite messy since it would have to figure out what RC format it was originally in. It would be much better if LIRC could just send the RC5 code directly into the kernel. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
