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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
