From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org, Jeff LaBundy <jeff@labundy.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] Input: make sure input handlers define only one processing method
Date: Mon, 1 Jul 2024 09:26:25 -0700 [thread overview]
Message-ID: <ZoLYscmmUR7Fu76F@google.com> (raw)
In-Reply-To: <cg35cp36opttnr2jgsqda2gsgqdn6vplc2pq3n3of3e356igua@vei6pdsw25si>
Hi Benjamin,
On Mon, Jul 01, 2024 at 09:36:08AM +0200, Benjamin Tissoires wrote:
> Hi Dmitry,
>
> On Jun 30 2024, Dmitry Torokhov wrote:
> > Input core expects input handlers to be either filters, or regular
> > handlers, but not both. Additionally, for regular handlers it does
> > not make sense to define both single event method and batch method.
> >
> > Refuse registering handler if it defines more than one method.
> >
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > ---
> > drivers/input/input.c | 24 ++++++++++++++++++++++++
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/input/input.c b/drivers/input/input.c
> > index fd4997ba263c..8434348faeac 100644
> > --- a/drivers/input/input.c
> > +++ b/drivers/input/input.c
> > @@ -2517,6 +2517,26 @@ void input_unregister_device(struct input_dev *dev)
> > }
> > EXPORT_SYMBOL(input_unregister_device);
> >
> > +static int input_handler_check_methods(const struct input_handler *handler)
> > +{
> > + int count = 0;
> > +
> > + if (handler->filter)
> > + count++;
> > + if (handler->events)
> > + count++;
> > + if (handler->event)
> > + count++;
> > +
> > + if (count != 1) {
>
> Am I missing some upstream commit? I have the following:
Thank you for the thorough review!
>
> in drivers/input/evdev.c:
>
> static struct input_handler evdev_handler = {
> .event = evdev_event,
> .events = evdev_events,
> .connect = evdev_connect,
> .disconnect = evdev_disconnect,
> .legacy_minors = true,
> .minor = EVDEV_MINOR_BASE,
> .name = "evdev",
> .id_table = evdev_ids,
> };
>
> So here count should be 2 and evdev would be rejected?
Uh, it looks like I had a patch buried that removed evdev_event as not
needed - if a handler has ->events() then input core would favor it even
before my patches.
>
> And in drivers/tty/serial/kgdboc.c:
>
> static struct input_handler kgdboc_reset_handler = {
> .connect = kgdboc_reset_connect,
> .disconnect = kgdboc_reset_disconnect,
> .name = "kgdboc_reset",
> .id_table = kgdboc_reset_ids,
> };
>
> here count would be 0 and kgdboc would also be rejected.
Yes, you are totally right. It looks like we need to allow the "no methods"
case.
>
> I agree on the intent of the patch, but these couple of input handlers
> should be fixed if they are not already.
Yep, I will address your other comments and resend in a few.
Thanks again!
--
Dmitry
next prev parent reply other threads:[~2024-07-01 16:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-01 6:05 [PATCH 0/4] Simplify event handling logic in input core Dmitry Torokhov
2024-07-01 6:05 ` [PATCH 1/4] Input: make sure input handlers define only one processing method Dmitry Torokhov
2024-07-01 7:36 ` Benjamin Tissoires
2024-07-01 16:26 ` Dmitry Torokhov [this message]
2024-07-01 6:05 ` [PATCH 2/4] Input: make events() method return number of events processed Dmitry Torokhov
2024-07-01 7:37 ` Benjamin Tissoires
2024-07-01 6:05 ` [PATCH 3/4] Input: simplify event handling logic Dmitry Torokhov
2024-07-01 7:41 ` Benjamin Tissoires
2024-07-01 16:31 ` Dmitry Torokhov
2024-07-01 17:54 ` Benjamin Tissoires
2024-07-01 6:05 ` [PATCH 4/4] Input: preallocate memory to hold event values Dmitry Torokhov
2024-07-01 7:53 ` Benjamin Tissoires
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZoLYscmmUR7Fu76F@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=bentiss@kernel.org \
--cc=jeff@labundy.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.