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

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

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