Hi Antti, Em Wed, 05 Feb 2014 09:03:29 +0200 Antti Seppälä <a.seppala@xxxxxxxxx> escreveu: > On 4 February 2014 19:54, Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx> wrote: > > Em Thu, 23 Jan 2014 21:11:09 +0200 > > Antti Seppälä <a.seppala@xxxxxxxxx> escreveu: > > > >> On 23 January 2014 00:01, Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx/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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
