I have a problem which is becoming a nightmare, to the extent that I am thinking that it might be easier to just scrap Ubuntu completely and try something else. I have an HP PC running Ubuntu 12.04. When I left-click with my mouse, it sometimes double-clicks (maybe 50% of the time).

So far this has led to: randomly sending unfinished emails, randomly highlighting and deleting things I didn't want to delete whilst writing emails (very frustrating), randomly deleting two browser tabs instead of one (several times), and (in some sense the most annoying) a very very frustating end-user experience when attempting to move windows around on the desktop or to cut-and-paste from a terminal window. Thank goodness for Alt-F7 — but I don't want to have to learn keyboard shortcuts for every program I use as well as for the OS (and not being able to copy-paste is a great loss for me).

I am not the only person with this problem, but googling indicates that there may well be multiple reasons for it; none of the fixes I have read online have worked for me. Let me go through everything, including fixes that have worked for other people but not for me. Oh — I have an hp optical mouse.

  • It is not a broken mouse. I have tried two mice on my system — both exhibit the problem. Both of these mice work fine on my home laptop also running Ubuntu 12.04.

  • My /etc/X11/xorg.conf is only a few lines long and has no "InputDevice" section.

  • I don't have hald, or the hal package installed.

  • It started about a week ago, and doesn't seem to be getting any better or worse.

  • In desperation I just upgraded to 12.10 but this has not fixed the problem and now I am running a distro that is not an LTS (and hence is not ideal for me :-\ )

But it is rendering my system very hard to use.

Possibly important update: I tried doing some investigations with xev. It seems to me that it looks like a bad connection in these mice -- is this common? I can hold down the mouse button, and then get (mouse click) (pause) (mouse release) (very very short pause) (mouse click) (pause) (mouse release) (very very short pause) (mouse click) etc. I wonder whether e.g. other operating systems say "you can't release and then click again within 0.05 seconds, so that must have been a glitch and I'll assume the button was never released". Can I tell Ubuntu to ignore release-and-then-reclick-almost-instantly events??

This so looks like a bad mouse issue. Maybe I should dig out a newer mouse? I've only tried very old ones :-\

  • 1
    have you reported it as a bug on launchpad?
    – Alvar
    Jul 19, 2013 at 9:08
  • Can you recall what happened one week ago, when it all started?
    – hytromo
    Jul 19, 2013 at 9:39
  • What happened a week ago is exactly what happens every week -- I just click on "install upgrades" and occasionally on "reboot computer to finish installation". This system is straight out the box -- I think that the only packages I installed other than those which are there by default were the few I needed to get sparkleshare running. Jul 19, 2013 at 10:26
  • 1
    @Alvar: there seems to be confusion on launchpad about this bug. My general impression is that some people get this problem and the issue is that their mouse is broken, some people get this problem and the issue is some logitech driver, and some people get this problem and the issue is somewhere else. I will try to report it and reduce the noise... Jul 19, 2013 at 10:28
  • I hit the related problem which I thought was broken mouse in combination with firefox gestures, but it turned out to be side buttons on the mouse doing "firefox back" Aug 17, 2017 at 14:11

8 Answers 8


OK after extensive testing using xev on the affected machine, and switching around between various mice on various systems, I believe I have solved this problem. Of course YMMV.

My solution: it is a broken mouse.

More precisely, the connector activated when clicking is a bit old or dirty or something, and sometimes, when holding the button down, the connection is made, and then momentarily broken, and then made again, causing the double click.

Objection: But the mouse works fine when I plug it into my Windows machine!

Counter: Wouldn't it be just trivial to put into a driver, or an OS, the following line of pseudocode: "if the user unclicks the mouse and then clicks it again within 0.05 seconds, then that's probably a dirty connector, so let's just ignore that". Thus isn't it possible that if you switch your mouse to another computer running another OS and/or using another driver on different hardware (even with the same OS you could well be using different hardware, right?), you could get different results?

Objection: But I tried another old mouse and it exhibited the same problem!

Counter: amazing how two old mice from the same company can both break in the same way, eh? And you never noticed because that second old mouse you tried was exhibiting no problems when plugged into different hardware (see previous counter).

If you really don't believe your mouse is broken, then test it:

$ xev

and then find the square with the black background, click in it, and watch the output. Do you definitely, always, get one clean "click" and nothing else? I would often get a clean click but occasionally a "bounce "(click unclick click). Even better perhaps:

$ xev | grep ButtonRelease

Now stick the mouse into the square with the black outline (or anywhere in that window) and click and unclick 20 times. You should get a "ButtonRelease" line every time you release the button, and never otherwise. I would occasionally get one when I clicked.

Nightmare over.

  • I've got two identical mice that I have noticed unexpected clicking with recently, and I'm not so sure both just 'wore out' the same week. Your xev test didn't give me anything unusual but I have to wonder if there is more to this? Jul 22, 2013 at 9:55
  • Right -- I was very suspicious about having two mice and neither of them working on one machine and both working on another one. I am pretty sure there are people out there who believe that there really is a problem other than "mice all broken and OS not compensating for it as well as other OS's". On the other hand I definitely jumped ship this morning -- my system is working again and I was convinced last week that the mouse couldn't be the problem, but for me it really was. Jul 22, 2013 at 11:41
  • 2
    With me I spent a good 5-10 minutes playing with xev and watching the output. Constantly clicking and unclicking etc etc -- and then just occasionally getting unexpected unclicks when I wasn't unclicking. Let me say also that looking at the output of xev on an 80x24 terminal window can be very misleading, because "unclick-click" can result in an entire page full of information being outputted by xev, and if the unclick-click happens sufficiently quickly (which was the case in my case) then you might not even be able to notice the xev output because it's almost identical to the page before. Jul 22, 2013 at 11:43
  • 12
    Better yet xev | awk '/ButtonRelease/ {print $1,i++}'.
    – arekolek
    Sep 11, 2016 at 18:31
  • For me, this manifested as "button 3" (the right mouse button) sending a signal occasionally when I would scroll up on my mouse wheel. Bizarre. Oct 17, 2017 at 23:50

Zen and mouse maintenance. Seems many are having a problem with the mouse double clicking when one click is applied. The mouse button is a micro switch. The fact of life is that switch contacts bounce. They don’t actually bounce but rub. We will call it bounce anyway. For some reason the programmers have dropped the ball on this one. A wait loop of sufficient duration should be applied for the contacts to settle before reading. Apropos of nothing and on a sample of one my solution has been to place a capacitor across the switch contacts. I used a 0.1uF cap for no particular reason other than I had one in a small size that would fit inside the mouse nicely. I haven’t done any fancy analyses of dwell time, time constants or decision levels to find an optimum value. Various models will have different parameters anyway.

I have been using this modification for some time and the problem hasn’t resurfaced so far.

To apply the mod. Find a capacitor of small physical dimensions that will fit inside to mouse case. I used a 0.1uF because I had one and it is a nice number but other values will probably work but don’t go too large or too small. What is too large or small is a matter for experiment. Too large may affect intended double clicks, too small won’t achieve the desired effect. I soldered one leg of the cap at a convenient location, where it didn’t run foul of the inside structure of the mouse, on the copper side of the board, to the 0 volt plane (earth plane if you wish) I hooked the other leg of the cap to the switch active with a bit of thin wire. I used a recycled component with short legs. A new one would likely have long enough legs to reach to where it is needed. You will need a suitable fine tipped soldering iron for the job.

If you don’t know capacitors. A 0.1uF capacitor may be designated 0.1uF or 104 or 100nF or have brown black yellow coloured bands. A surface mount type would be a good choice also. Hook it in with some strands of fine wire. Could glue it to the board connection side up.

I have a plan B which I may try next time or if the current plan eventually fails. Ditching the micro switch for a spst PCB mount tactile membrane switch should solve the problem. That is the type of switch used in keyboards and key pads and don’t exhibit this problem. The foot print it nothing like the micro switch. A switch 7mm high is available which will come in at the same height as the existing micro switch. A smaller switch would need to be spaced up to the correct height. Bend the legs at right angles to the switch body and glue it to the board so that the actuator aligns with the position occupied by the micro switch actuator. The mouse button has to hit the correct spot. Wire the switch contacts in with some fine wire and all should be good in theory.

  • 6
    Although your answer is 100% correct, this is a Software Q&A site, not a hardware Q&A. So please: 1/ add a respectable warning that you're giving a HW solution for a SW problem, 2/ shorten your answer 3/ Add some links to pictures on how to do this 4/ It's µF, not uF.
    – Fabby
    Feb 12, 2015 at 11:03
  • @Fabby Your suggestions (1) and (3) are excellent, but not so much with (2), and (3) is petty/unnecessary. Also comes off as a bit snarky/terse. You should try to be friendly to new users! :)
    – user606179
    Jun 11, 2019 at 8:59
  • @Joe 1/ Look at upvotes for comment. 2/ Yeah, it's telegram style without any niceties, so that could have been better. In my defence: I'm a Vorlon, not a Human and I'm still working on my empathy... ;-)
    – Fabby
    Jun 11, 2019 at 19:42
  • The important part is that the hardware is broken. The debouncing must be implemented in hardware because the required debounce time depends on the actual hardware implementation so it cannot be safely implemented with software. Usually the problem is low quality microswitch so if you're going to start soldering stuff, it's usually the best to simply replace the poor quality microswitch. Adding a capacitor will in practice increase the debounce filtering time and it allows already partially failing switches to be usable for longer. Sep 14, 2022 at 19:07

I've built a patched xserver-xorg-input-evdev for Ubuntu 14.10. I used the instructions from http://blog.guntram.de/?p=16 (patch can be found here and here) and a Debian packaging manual.

Here are my notes about building a package.

# http://blog.guntram.de/?p=16

apt-get build-dep xserver-xorg-input-evdev

dquilt="quilt --quiltrc=${HOME}/.quiltrc-dpkg"

wget --output-document=evdev-debounce.patch http://blog.guntram.de/?ddownload=20
apt-get source xserver-xorg-input-evdev

cd xserver-xorg-input-evdev-*

$dquilt new debounce.patch
$dquilt add include/evdev-properties.h src/Makefile.am src/debounce.c src/evdev.c src/evdev.h src/debounce.c
patch -p1 <../evdev-debounce.patch

$dquilt refresh
$dquilt header -e

debuild -us -uc -b
cd ..

sudo dpkg -i xserver-xorg-input-evdev_*.deb
  • Good news: it worked.
  • Bad news: it doesn't always help. My mouse button contact was so bad that it needed a 200ms delay, which stops me from double-clicking. Another bouncing mouse began working fine.

edit: Thanks @MatijaNalis, the patch obtaining steps could be:

wget https://aur.archlinux.org/packages/xf/xf86-input-evdev-debounce/xf86-input-evdev-debounce.tar.gz
tar xzf xf86-input-evdev-debounce.tar.gz
# ...
patch -p1 < ../xf86-input-evdev-debounce/debounce.patch
  • 1
    script needs changing - "dquilt new" misses "$", "patch" should be after "$dquilt add" and before "$dquilt refresh", and patch on blog.guntram.de is old, one should use other one from aur.archlinux.org. "apt-get build-dep xserver-xorg-input-evdev" should also be added. Also should use quilt environment variables instead of (unspecified) config files - wiki.debian.org/UsingQuilt. Otherwise, looks like great workaround for broken mouse... May 31, 2015 at 22:49
  • 5
    A debouncing feature was added to libinput 1.9 (unix.stackexchange.com/a/451864/116842).
    – Jérôme
    Jun 25, 2018 at 22:02

The problem, explained by Jack Ganssle, here: http://www.eng.utah.edu/~cs5780/debouncing.pdf
- contact bounce filtering. The software thingy needs to be there in any application, from simple single-board computers to operating systems, in some form.


As contacts / buttons get older, the effect will get worse. WD40 might not be the best spray to use on electronics, there are others more suiting. Google 'Contact spray'.


In my case it was hardware or, more precisely, some mechanical problem with mouse button micro switch.

I had this problem with 2 mice: the old one Logitech m-uv69 and some another mouse I've bought about a year ago and I managed to repair both of them without much effort. This is what I have done:

  • took off mouse top cover
  • directly quickly pushed micro switch small button many times

After that almost all unintentional doubleclicks gone away. I don't know what exactly caused them inside micro switch. Probably it got dirty or something and quickly pushing it makes the dirt go away.

  • Wow thank you for that; I was about to buy another mouse but I first tried your solution and it fixed my issue!
    – bfontaine
    May 17 at 14:04

I had a problem with an additional button clicking twice. As I already had it mapped with xbindkeys (see How can I assign actions to all my mouse buttons? for more information on that) my solution was changing the entry in the ~/.xbindkeysrc as follows:

"if [ ! -e /dev/shm/button ]; then touch /dev/shm/button; /usr/bin/xte 'keydown Control_L' 'key Page_Down' 'keyup Control_L'; sleep 0.2; rm  /dev/shm/button; fi"

This creates a "lockfile" for every button press in /dev/shm/(which I hope lies on RAM) and removes it after 0.2 seconds. And the xte command shall be done on mouse click and shall not be done twice in 0.2 seconds.

(Just thought I'd share my solution, in case anybody want's to copy it or to fix it.)

  • This is an excellent solution for cases where the mouse sends a continuous ButtonPress/ButtonRelease event stream, but you want to convert it into a single event. This happens with e.g. Microsoft bluetooth mouse and tilt wheel buttons. Oct 12, 2018 at 21:52

Spray WD40 is magic for many problems, inclusive volume wheel in headphones with rac rac rac noises, also for repair this problem of mouse clicks…

Test, is a very fast, not need open the mouse or open the headphones, spray and go well another time…


There is a software bug and as of June 2014 there is no fix for it. It does not happen on all mice modles. My logitech mice are fine but most other fail no matter what you do. This is for RHEL, CentOS and Ubuntu. All the mice work on pure windows boxes but the same issue is there in KVM's

No Solution yet, Developers do know about it.

Cheers. Don.

  • 1
    Could you add a link to the bug and give a little background about it?
    – Oli
    Jun 27, 2014 at 22:46
  • 2
  • 3
    As you can see from the other answers (and the bug report), this is not actually a bug, but rather a missing feature. Windows does debounce filtering on mice by default, while Linux doesn't.
    – Hjulle
    Apr 12, 2016 at 11:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .