[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181215094722.GA5804@amd>
Date: Sat, 15 Dec 2018 10:47:22 +0100
From: Pavel Machek <pavel@....cz>
To: Vojtech Pavlik <vojtech@...e.cz>
Cc: kernel list <linux-kernel@...r.kernel.org>, jikos@...e.cz,
linux-input@...r.kernel.org, dmitry.torokhov@...il.com
Subject: Re: [rfd] saving old mice -- button glitching/debouncing
Hi!
> > 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.
It seems mice normally survive 2 years under my use. This one has left
button repaired and middle button failing... If debouncing gives it
one more year, it will be success...
> > 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.
Not... really, right? You need to send an release some time after
button indicates release if bounce did not happen. It is similar to
autorepeat needing a timer.
Let me gain some experience with the patch. I don't think hardware
does as heavy debouncing as you describe.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists