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

[Mauro Carvalho Chehab <m.chehab@samsung.com>]

Em Wed, 05 Feb 2014 20:16:04 +0200
Antti Seppälä <a.seppala@gmail.com> escreveu:

> On 5 February 2014 11:42, James Hogan <james.hogan@imgtec.com> wrote:
> > 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.
> >>
> 
> Yes, in nuvoton the ir pulses correspond to a scancode (or part of a scancode)
> 
> After giving it some thought I agree that using scancodes is the most
> elegant way for specifying wakeup commands. Too bad that nuvoton does
> not work with scancodes.
> I pretty much agree with Mauro that the right solution would be to
> write an IR encoder and use it to convert the given scancode back to a
> format understood by nuvoton.

Ok, as we all agreed, I'll merge the remaining patches from James.

> Writing IR encoders for all the protocols and an encoder selector
> functionality is quite labourous and sadly I don't have time for that
> anytime soon. If anyone wants to step up I'd be more than happy to
> help though :)

I suspect that writing one IR encoder should not be hard, as there
are already some on LIRC userspace.

I would love to have some time to write at least a few IR encoders,
but, unfortunately, I would not have any time soon.

Regards,
Mauro