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

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

On 05/02/14 21:21, Mauro Carvalho Chehab wrote:
> 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.

Thanks :)

> 
>> 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.

For fun, I did some experimentation yesterday evening with adding basic
generic IR encoding (just NEC implemented so far). Encoders can
certainly be a lot simpler than decoders.

I'll submit a few RFC patches later so Antti can see whether it would be
suitable for nuvoton.

Cheers
James