On 26 March 2014 01:21, David Härdeman <david@xxxxxxxxxxx> wrote: > On Tue, Mar 25, 2014 at 09:12:11AM +0000, James Hogan wrote: >>On Tuesday 25 March 2014 00:51:46 David Härdeman wrote: >>> On Fri, Feb 28, 2014 at 11:17:02PM +0000, James Hogan wrote: >>> >Add generic scancode filtering of RC input events, and fall back to >>> >permitting any RC_FILTER_NORMAL scancode filter to be set if no s_filter >>> >callback exists. This allows raw IR decoder events to be filtered, and >>> >potentially allows hardware decoders to set looser filters and rely on >>> >generic code to filter out the corner cases. >>> >>> Hi James, >>> >>> What's the purpose of providing the sw scancode filtering in the case where >>> there's no hardware filtering support at all? >> >>Consistency is probably the main reason, but I'll admit it's not perfectly >>consistent between generic/hardware filtering (mostly thanks to NEC scancode >>complexities), and I have no particular objection to dropping it if that isn't >>considered a good enough reason. > > I'm kind of sceptical...and given how difficult it is to remove > functionality that is in a released kernel...I think that particular > part (i.e. the software filtering) should be removed until it has had > further discussion... > >>Here's the original discussion: >>On Monday 10 February 2014 21:45:30 Antti Seppälä wrote: >>> On 10 February 2014 11:58, James Hogan <james.hogan@xxxxxxxxxx> wrote: >>> > On Saturday 08 February 2014 13:30:01 Antti Seppälä wrote: >>> > > Also adding the scancode filter to it would >>> > > demonstrate its usage. >>> > >>> > 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. >>> >>> Rc-core level scancode filtering shouldn't be too hard to do right? If >>> such would exist then it would provide a software fallback to other rc >>> devices where hardware filtering isn't available. I'd love to see the >>> sysfs filter and filter_mask files to have an effect on my nuvoton too > > I don't understand. What's the purpose of a "software fallback" for > scancode filtering? Antti? > Well since the ImgTec patches will create a new sysfs interface for the HW scancode filtering I figured that it would be nice for it to also function on devices which lack the hardware filtering capabilities. Especially since it's only three lines of code. :) Therefore I suggested the software fallback. At the time I had no clue that there might be added complexities with nec scancodes. So like James said it exists mainly for api consistency reasons. -Antti -- 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
