Re: [Question : drivers/input ] Fixing Event Filter Mechanism in input subsystem

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

Hi Anshul,

On Thu, Dec 25, 2014 at 11:11:06AM +0530, Anshul Garg wrote:
> Dear Mr Dmitry ,
> 
> Thanks a lot for the clarification.
> 
> I was in assumption that one handler can support both ->filter() and
> ->event[s]()
> Callback.So that's why i have prepared the patch to first do the
> filter then pass
> the events.
> 
> Can you please tell me why current implementation doesn't expect handler can
> have both callbacks?

Because it was something I saw no need for: filter already has all the
events so it can process them. If you really want to process events
again once all filters have run, you can register additional handler.

> 
> I think input core should be generic to allow any type of handlers which can
> support both filter and events callbacks.
> 
> Please help to answer above query as my patch is based on this pre-assumption
> that one handler can support both callbacks .
> 
> If we really need to have support of such handlers in input core then
> only my patch
> is good.

I think I would need a user for this feature before changing the code to
allow it.

Thanks.

-- 
Dmitry