Re: [PATCH] input: move check for same handler in input_pass_event

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

On Thu, Jan 20, 2011 at 12:56:54AM -0800, Dmitry Torokhov wrote:
> On Fri, Jan 07, 2011 at 11:43:13AM -0800, Dmitry Torokhov wrote:
> > On Fri, Jan 07, 2011 at 11:32:33AM -0800, Arjan van de Ven wrote:
> > > On 1/7/2011 11:29 AM, Dmitry Torokhov wrote:
> > > >On Fri, Jan 07, 2011 at 10:24:34AM -0800, Kristen Carlson Accardi wrote:
> > > >>On Thu, 6 Jan 2011 22:04:56 -0800
> > > >>Dmitry Torokhov<dmitry.torokhov@gmail.com>  wrote:
> > > >>
> > > >>>On Thu, Jan 06, 2011 at 02:24:48PM -0800, Kristen Carlson Accardi wrote:
> > > >>>>If the handler that injected an event is the same,
> > > >>>>just skip the filter, but allow the handler->event()
> > > >>>>routine to be called.  This allows evdev to be able to
> > > >>>>be used to loopback events.
> > > >>>Why is it needed? Could you please give some examples?
> > > >>>
> > > >>>Thanks.
> > > >>>
> > > >>We have a customer who has a touchscreen device which sends
> > > >>a bitmap into a gesture engine, which then interprets that
> > > >>result and feeds it back into the kernel through a virtual
> > > >>input driver that X is listening to.
> > > >That really should be done though uinput.
> > > 
> > > quite possible.
> > > 
> > > but the application already exists, and works just fine in 2.6.35...
> > > causing this to be classified as a kernel ABI regression ;-(
> > > 
> > 
> > Hmm... I'd probably call it "relying on implementation details not
> > spelled out anywhere".
> > 
> > Anyway, let me ponder this one a bit...
> > 
> 
> OK, I think if we apply the patch below and then completely revert
> 5fdbe44d033d059cc56c2803e6b4dbd8cb4e5e39 we'll get the behavior we
> want.
> 
> Jason, could you please try this and see if SysRq still works for you?
>

*ping*

Anyone?

Thanks.

-- 
Dmitry