Em Thu, 06 Feb 2014 10:46:04 +0000 James Hogan <james.hogan@xxxxxxxxxx> escreveu: > On 05/02/14 21:21, Mauro Carvalho Chehab wrote: > > Em Wed, 05 Feb 2014 20:16:04 +0200 > > Antti Seppälä <a.seppala@xxxxxxxxx> escreveu: > > > >> On 5 February 2014 11:42, James Hogan <james.hogan@xxxxxxxxxx> 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 :) Well, Rob asked some changes at the DT binding pathes. I'll tag the patches as changes requested. Please re-submit the remaining ones after fixing the pointed issues and getting his ack. Except for that, the series look OK on my eyes. > > > >> 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. Yes, you don't need to deal with time shifts there, nor with missing events ;) Well, using the encoders also for TX (as an another ioctl at LIRC) would require some extra bits to handle things like carrier frequency, duty cycle, etc, but lirc should be able to handle those already. So, a future patch expanding its usage to lirc would just need to add the proper binding. Btw, I just noticed that the LIRC UAPI interface is still at the wrong place. It is at: include/media/lirc.h but it should be at: include/uapi/.../lirc.h I'm wandering why nobody didn't notice it yet when compiling Lirc userspace... Perhaps userspace is just keeping a copy of that file without any process to sync it from the Kernel userspace headers. > I'll submit a few RFC patches later so Antti can see whether it would be > suitable for nuvoton. Thanks for that! 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
