Hi Antti, On 05/02/14 07:03, Antti Seppälä wrote: > To wake up with nuvoton-cir we need to program several raw ir > pulse/space lengths to the hardware and not a scancode. James's > approach doesn't support this. Do the raw pulse/space lengths your hardware requires correspond to a single IR packet (mapping to a single scancode)? If so then my API is simply at a higher level of abstraction. I think this has the following advantages: * userspace sees a consistent interface at the same level of abstraction as it already has access to from input subsystem (i.e. scancodes). I.e. it doesn't need to care which IR device is in use, whether it does raw/hardware decode, or the details of the timings of the current protocol. * it supports hardware decoders which filter on the demodulated data rather than the raw pulse/space lengths. Of course to support this we'd need some per-protocol code to convert a scancode back to pulse/space lengths. I'd like to think that code could be generic, maybe as helper functions which multiple drivers could use, which could also handle corner cases of the API in a consistent way (e.g. user providing filter mask covering multiple scancodes, which presumably pulse/space). I see I've just crossed emails with Mauro who has just suggested something similar. I agree that his (2) is the more elegant option. Cheers James -- 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
