Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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 :-\

share|improve this question
    
have you reported it as a bug on launchpad? –  Alvar Jul 19 '13 at 9:08
    
Can you recall what happened one week ago, when it all started? –  hakermania Jul 19 '13 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. –  Kevin Buzzard Jul 19 '13 at 10:26
    
@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... –  Kevin Buzzard Jul 19 '13 at 10:28

6 Answers 6

up vote 12 down vote accepted

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.

share|improve this answer
    
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? –  Tom Brossman Jul 22 '13 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. –  Kevin Buzzard Jul 22 '13 at 11:41
1  
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. –  Kevin Buzzard Jul 22 '13 at 11:43

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.

share|improve this answer
1  
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 at 11:03

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…

share|improve this answer

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.

share|improve this answer
1  
Could you add a link to the bug and give a little background about it? –  Oli Jun 27 '14 at 22:46
    

The problem explained 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.

https://www.google.se/?gfe_rd=cr&safe=off#q=%2Bcontact+%2Bbounce+%2Bsoftware&safe=off

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'.

share|improve this answer

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.

#!/bin/bash
# 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 mouse worked.

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
share|improve this answer
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... –  Matija Nalis yesterday

protected by Community Feb 13 at 7:45

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.