Re: [RFC PATCH 0/4] rc: Adding support for sysfs wakeup scancodes

[James Hogan <james.hogan@imgtec.com>]

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
>