From: Vojtech Pavlik <vojtech@suse.cz>
To: Pavel Machek <pavel@ucw.cz>
Cc: kernel list <linux-kernel@vger.kernel.org>,
jikos@suse.cz, linux-input@vger.kernel.org,
dmitry.torokhov@gmail.com
Subject: Re: [rfd] saving old mice -- button glitching/debouncing
Date: Sat, 15 Dec 2018 09:55:10 +0100 [thread overview]
Message-ID: <20181215085510.GB12930@suse.com> (raw)
In-Reply-To: <20181214232437.GA8310@amd>
On Sat, Dec 15, 2018 at 12:24:37AM +0100, Pavel Machek wrote:
> Patch is obviously not ready; but:
>
> a) would it be useful to people
Probably not.
Mice already do internal software/hardware debouncing on switches. If you
see duplicate clicks making it all the way to the kernel driver, something
is very wrong with the switch, to the point where it'll soon fail
completely.
Hence the value of doing extra processing in the kernel is very limited.
> b) would it be acceptable if done properly? (cmd line option to
> enable, avoiding duplicate/wrong events?)
Well, for one, you shouldn't be using a timer, all the debouncing can be
done by math on the event timestamps.
You'd also have a hard time distinguishing between doubleclicks and bounces.
Since the mice already filter the quick bounces and there is significant
delay (100ms on USB, similar on PS/2) between updates from the hardware, a
real doubleclick can look absolutely the same as what you observe as a
bounce.
As such, it couldn't be enabled by default.
If you really want to go this way, a userspace solution is the better choice.
--
Vojtech Pavlik
next prev parent reply other threads:[~2018-12-15 8:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-14 23:24 [rfd] saving old mice -- button glitching/debouncing Pavel Machek
2018-12-15 0:19 ` Dmitry Torokhov
2018-12-15 8:55 ` Vojtech Pavlik [this message]
2018-12-15 9:47 ` Pavel Machek
2018-12-15 10:12 ` Vojtech Pavlik
2018-12-15 10:29 ` Pavel Machek
2018-12-18 15:26 ` kbuild test robot
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=20181215085510.GB12930@suse.com \
--to=vojtech@suse.cz \
--cc=dmitry.torokhov@gmail.com \
--cc=jikos@suse.cz \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
/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 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).