Dear Mr. Dmitry , Thanks a lot for clearing my doubts :) On Sat, Dec 27, 2014 at 5:16 AM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > 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
