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

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

Hi Antti,

Em Wed, 05 Feb 2014 09:03:29 +0200
Antti Seppälä <a.seppala@gmail.com> escreveu:

> On 4 February 2014 19:54, Mauro Carvalho Chehab <m.chehab@samsung.com> wrote:
> > Em Thu, 23 Jan 2014 21:11:09 +0200
> > Antti Seppälä <a.seppala@gmail.com> escreveu:
> >
> >> On 23 January 2014 00:01, Mauro Carvalho Chehab <m.chehab@samsung.com> wrote:
> >> > Not sure if you saw it, but there's already another patchset proposing
> >> > that, that got submitted before this changeset:
> >> >         https://patchwork.linuxtv.org/patch/21625/
> >>
> >> I actually didn't notice that until now. Seems quite a similar kind of
> >> approach with even more advanced features than what I had in mind
> >> (namely the scancode filtering and masking).
> >>
> >> However it looks like that patchset has the same drawback about not
> >> knowing which protocol to use for the wakeup scancode as was pointed
> >> from my patch.
> >
> > Well, the protocol is important only if there are two or more active
> > RCs that produce the same IR code on different protocols.
> >
> > Also, from the sysfs description made by James, it seems clear to me
> > that the protocol to be used is the current protocol.
> >
> > I think is an unlikely border case to have some hardware that supports
> > more than one IR protocols enabled for the wakeup to work, so James
> > patch looks ok on my eyes.
> >
> > Also, nothing prevents to add latter a wakeup_filter_protocol sysfs node
> > to allow to filter the wakeup scancode to a protocol set different than
> > the one(s) currently enabled.
> >
> >> I think I'll try to come up with a new patch addressing the comments
> >> I've seen so far.
> >
> > I guess I'll merge James approach, as there are a pile of other patches
> > depending on it. If we need latter to distinguish between current_protocol
> > and the wakeup one, as I said, a latter patch can add a
> > "wakeup_filter_protocol" sysfs node to specify it.
> >
> > Regards,
> > Mauro
> 
> Hi Mauro.
> 
> How do you want to proceed with the nuvoton wakeup I initially set out to do?
> 
> 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.
> 
> To keep things simple maybe module parameters in my first patch
> (http://www.mail-archive.com/linux-media@vger.kernel.org/msg69782.html)
> are then the best thing to do for nuvoton? Other drivers can probably
> adapt to the suggested filter api.

Well, you're basically telling that you need an IR encoder to convert
from protocol/scancode into pulse/space lengths. 

As we need/want a portable interface that will provide the same API
to  userspace, no matter what hardware, I can see two alternatives:

1) Use a lirc-like API for that, using the IR encoder code in userspace;

2) The same way as we mapped IR decoders, add IR encoders that can be
used either for IR TX or to provide IR wakeup codes.

IMO, (2) is a much more elegant option.

Regards,
Mauro