Hi Antti, On 08/02/14 11:30, Antti Seppälä wrote: >> The first patch adds an encode callback to the existing raw ir handler >> struct and a helper function to encode a scancode for a given protocol. >> > > The mechanism used here to encode works fine as long as there is only > one protocol selected. If there are several which all support encoding > then there's no easy way to tell which one will be used to do the > actual encoding. True, I suppose it needs a wakeup_protocol sysfs file for that really (I can't imagine a need or method to wake on multiple protocols, a demodulating hardware decoder like img-ir can only have one set of timings at a time, and a raw hardware decoder like nuvoton would seem unlikely to have multiple wake match buffers - and if it did the sysfs interface would probably need extending to take multiple single-protocol/filter sets anyway). This should probably be done prior to the new sysfs interface reaching mainline, so that userland can always be expected to write the protocol prior to the wakeup filter (rather than userland expecting the wake protocol to follow the current protocol). >> Finally for debug purposes patch 4 modifies img-ir-raw to loop back the >> encoded data when a filter is altered. Should be pretty easy to apply >> similarly to any raw ir driver to try it out. >> > > I believe we have rc-loopback driver for exactly this purpose. Could > you use it instead? Also adding the scancode filter to it would > demonstrate its usage. True I could have done, I used img-ir simply out of convenience and familiarity :). Would it make sense to generate an input event when setting the filter though, or perhaps since the whole point of the loopback driver is presumably debug it doesn't matter? To actually add filtering support to loopback would require either: * raw-decoder/rc-core level scancode filtering for raw ir drivers * OR loopback driver to encode like nuvoton and fuzzy match the IR signals. > One other thing I noticed while reviewing your patches was that > currently the dev->s_filter callback return value is ignored by > store_filter. It would be useful to return an error to userspace if > scancode storage was not possible for whatever reason. Thanks, well spotted, I'll do a fix for that soon. Cheers James
Attachment:
signature.asc
Description: OpenPGP digital signature
