On 05/02/14 09:39, James Hogan wrote: > 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). hmm, I didn't complete that sentence :(. I meant: ..., which presumably pulse/space can't really represent very easily). Cheers James > > 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
