* [PATCH] input: move check for same handler in input_pass_event @ 2011-01-06 22:24 Kristen Carlson Accardi 2011-01-06 22:29 ` Kristen Carlson Accardi 2011-01-07 6:04 ` Dmitry Torokhov 0 siblings, 2 replies; 9+ messages in thread From: Kristen Carlson Accardi @ 2011-01-06 22:24 UTC (permalink / raw) To: linux-input; +Cc: Kristen Carlson Accardi 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. --- drivers/input/input.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/input/input.c b/drivers/input/input.c index db409d6..cdeb929 100644 --- a/drivers/input/input.c +++ b/drivers/input/input.c @@ -98,16 +98,15 @@ static void input_pass_event(struct input_dev *dev, * particular event we want to skip it to avoid * filters firing again and again. */ - if (handler == src_handler) - continue; - if (!handler->filter) { if (filtered) break; handler->event(handle, type, code, value); - } else if (handler->filter(handle, type, code, value)) + } else if (handler != src_handler && + handler->filter(handle, type, code, + value)) filtered = true; } } -- 1.7.2.3 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH] input: move check for same handler in input_pass_event 2011-01-06 22:24 [PATCH] input: move check for same handler in input_pass_event Kristen Carlson Accardi @ 2011-01-06 22:29 ` Kristen Carlson Accardi 2011-01-07 6:04 ` Dmitry Torokhov 1 sibling, 0 replies; 9+ messages in thread From: Kristen Carlson Accardi @ 2011-01-06 22:29 UTC (permalink / raw) To: linux-input; +Cc: Kristen Carlson Accardi 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. Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> --- drivers/input/input.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/input/input.c b/drivers/input/input.c index db409d6..cdeb929 100644 --- a/drivers/input/input.c +++ b/drivers/input/input.c @@ -98,16 +98,15 @@ static void input_pass_event(struct input_dev *dev, * particular event we want to skip it to avoid * filters firing again and again. */ - if (handler == src_handler) - continue; - if (!handler->filter) { if (filtered) break; handler->event(handle, type, code, value); - } else if (handler->filter(handle, type, code, value)) + } else if (handler != src_handler && + handler->filter(handle, type, code, + value)) filtered = true; } } -- 1.7.2.3 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] input: move check for same handler in input_pass_event 2011-01-06 22:24 [PATCH] input: move check for same handler in input_pass_event Kristen Carlson Accardi 2011-01-06 22:29 ` Kristen Carlson Accardi @ 2011-01-07 6:04 ` Dmitry Torokhov 2011-01-07 18:24 ` Kristen Carlson Accardi 1 sibling, 1 reply; 9+ messages in thread From: Dmitry Torokhov @ 2011-01-07 6:04 UTC (permalink / raw) To: Kristen Carlson Accardi; +Cc: linux-input 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. -- Dmitry ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] input: move check for same handler in input_pass_event 2011-01-07 6:04 ` Dmitry Torokhov @ 2011-01-07 18:24 ` Kristen Carlson Accardi 2011-01-07 19:29 ` Dmitry Torokhov 0 siblings, 1 reply; 9+ messages in thread From: Kristen Carlson Accardi @ 2011-01-07 18:24 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-input, arjan 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] input: move check for same handler in input_pass_event 2011-01-07 18:24 ` Kristen Carlson Accardi @ 2011-01-07 19:29 ` Dmitry Torokhov 2011-01-07 19:32 ` Arjan van de Ven 0 siblings, 1 reply; 9+ messages in thread From: Dmitry Torokhov @ 2011-01-07 19:29 UTC (permalink / raw) To: Kristen Carlson Accardi; +Cc: linux-input, arjan 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. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] input: move check for same handler in input_pass_event 2011-01-07 19:29 ` Dmitry Torokhov @ 2011-01-07 19:32 ` Arjan van de Ven 2011-01-07 19:43 ` Dmitry Torokhov 0 siblings, 1 reply; 9+ messages in thread From: Arjan van de Ven @ 2011-01-07 19:32 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Kristen Carlson Accardi, linux-input 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 ;-( ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] input: move check for same handler in input_pass_event 2011-01-07 19:32 ` Arjan van de Ven @ 2011-01-07 19:43 ` Dmitry Torokhov 2011-01-20 8:56 ` Dmitry Torokhov 0 siblings, 1 reply; 9+ messages in thread From: Dmitry Torokhov @ 2011-01-07 19:43 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Kristen Carlson Accardi, linux-input 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... -- Dmitry ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] input: move check for same handler in input_pass_event 2011-01-07 19:43 ` Dmitry Torokhov @ 2011-01-20 8:56 ` Dmitry Torokhov 2011-01-26 4:59 ` Dmitry Torokhov 0 siblings, 1 reply; 9+ messages in thread From: Dmitry Torokhov @ 2011-01-20 8:56 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Kristen Carlson Accardi, linux-input, Jason Wessel 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? Thanks! -- Dmitry Input: sysrq - rework re-inject logic From: Dmitry Torokhov <dmitry.torokhov@gmail.com> Internally 'disable' the filter when re-injecting Alt-SysRq instead of relying on input core to suppress delivery of injected events to the originating handler. This allows to revert commit 5fdbe44d033d059cc56c2803e6b4dbd8cb4e5e39 which causes problems with existing userspace programs trying to loopback the events via evdev. Reported-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> --- drivers/tty/sysrq.c | 17 ++++++++++++++++- 1 files changed, 16 insertions(+), 1 deletions(-) diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c index c556ed9..ef3a983 100644 --- a/drivers/tty/sysrq.c +++ b/drivers/tty/sysrq.c @@ -571,6 +571,7 @@ struct sysrq_state { unsigned int alt_use; bool active; bool need_reinject; + bool reinjecting; }; static void sysrq_reinject_alt_sysrq(struct work_struct *work) @@ -581,6 +582,10 @@ static void sysrq_reinject_alt_sysrq(struct work_struct *work) unsigned int alt_code = sysrq->alt_use; if (sysrq->need_reinject) { + /* we do not want the assignment to be reordered */ + sysrq->reinjecting = true; + mb(); + /* Simulate press and release of Alt + SysRq */ input_inject_event(handle, EV_KEY, alt_code, 1); input_inject_event(handle, EV_KEY, KEY_SYSRQ, 1); @@ -589,6 +594,9 @@ static void sysrq_reinject_alt_sysrq(struct work_struct *work) input_inject_event(handle, EV_KEY, KEY_SYSRQ, 0); input_inject_event(handle, EV_KEY, alt_code, 0); input_inject_event(handle, EV_SYN, SYN_REPORT, 1); + + mb(); + sysrq->reinjecting = false; } } @@ -599,6 +607,13 @@ static bool sysrq_filter(struct input_handle *handle, bool was_active = sysrq->active; bool suppress; + /* + * Do not filter anything if we are in the process of re-injecting + * Alt+SysRq combination. + */ + if (sysrq->reinjecting) + return false; + switch (type) { case EV_SYN: @@ -629,7 +644,7 @@ static bool sysrq_filter(struct input_handle *handle, sysrq->alt_use = sysrq->alt; /* * If nothing else will be pressed we'll need - * to * re-inject Alt-SysRq keysroke. + * to re-inject Alt-SysRq keysroke. */ sysrq->need_reinject = true; } ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] input: move check for same handler in input_pass_event 2011-01-20 8:56 ` Dmitry Torokhov @ 2011-01-26 4:59 ` Dmitry Torokhov 0 siblings, 0 replies; 9+ messages in thread From: Dmitry Torokhov @ 2011-01-26 4:59 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Kristen Carlson Accardi, linux-input, Jason Wessel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-01-26 4:59 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-01-06 22:24 [PATCH] input: move check for same handler in input_pass_event Kristen Carlson Accardi 2011-01-06 22:29 ` Kristen Carlson Accardi 2011-01-07 6:04 ` Dmitry Torokhov 2011-01-07 18:24 ` Kristen Carlson Accardi 2011-01-07 19:29 ` Dmitry Torokhov 2011-01-07 19:32 ` Arjan van de Ven 2011-01-07 19:43 ` Dmitry Torokhov 2011-01-20 8:56 ` Dmitry Torokhov 2011-01-26 4:59 ` Dmitry Torokhov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).