For a very long time now (years) through several generations of OS, I have noticed a rather irritating behaviour of my USB mouse. Currently I am running OpenSuse 13.2 (64-bit) with Gnome 3.14.2, but the issue is not new to this version.
The behaviour in question is that the mouse begins to double-click spontaneously, at random, after sometimes after weeks of apparently ‘normal’ behaviour. Of course, firstly, I played around with the mouse parameters under the Gnome ‘Mouse and Touchpad’ utility. That provided no evident relief. I thought that before I raise the question in the forum, I had better suspect my mouse hardware. But even when I used another USB mouse, it started to happen after a while. Recently, I became so irritated with this behaviour, I went an bought a brand new one. And it happens with that as well, irrespective of whether the double-click setting is fully fast or fully slow, or anywhere in between.
My conclusion: there is something wrong with the mouse ‘driver’ software! I wonder if anyone else can concur with me on this rather elusive, but exceedingly irritating, point?:\
It is irritating, because, for example, two emails get deleted when only one was meant, and, worse, one doesn’t notice it! Or, one tries to select Gnome, ‘Activities’ and the second unwanted click returns to the screen back to the original. After one or two (or more) attempts it succeeds. In the internet, it can be particularly risky, causing a click on a link one didn’t even know existed.
There is only one user (plus root) on the PC in question. Moreover, this phenomenon as followed me over various version of OS, with various ‘new’ installations, so I guess, in that sense there have been ‘different’ users and different desktops.
By different desktop do you mean KDE or LFCE (or whatever it is called:)) instead of Gnome? I’ve tried that in the past and messed up my system big time that way.
My idea is that something in one of the configuration files for the desktop is messed. Since Linux is multi user each user account has their own settings. Trying a different user (create if needed) will use a different set of config files. A different desk top (you can install more then one and generally several simple ones are installed just logout and select a different one) will rule in or out Gnome itself. Another possibility is a messed up xorg.conf file. I doubt it is the software itself or other would be reporting it.
On my first login to IceWM, with my own account, the problem was very evident. Back to Gnome, the problem was not so evident, rather sporadical. Return to IceWM, no sign of it now. However, this time IceWM resolutely refused to logout, reboot or shut down. After about 20 minutes, I tried shutdown from the terminal with success. After reboot into Gnome, the problem was very evident again.
Well it is not the mouse it is not the USB port it is not gnome it is not a user config problem. I’m not sure about the xorg. Do you have a /etc/X11/xorg.conf file? or modified any files in /etc/X11/xorg.conf.d directory??
If so let see 'em
Since this has occurred of different OS version and others are not seeing the problem. Maybe some funky hardware. Any of those USB USB3? if so try USB2 slot. Note that many mother boards will have 2 USB controllers each controlling several slots. be sure you have tried all USB ports
I certainly haven’t modified any files in /etc/X11/xorg.conf.d and there is no file called xorg.conf (one called xorg.conf.install is there). Almost certainly I have no USB3 ports. My PC is a second-hand Dell desktop (Optiplex GX620), bought from my company when they were upgrading about 4 years ago. The Dell mouse is one of the suspects and the newest one, a Speedlink JIGG Mouse seems to behave even more erratically. There are 6 USB ports in the PC and another two available in the (Dell) keyboard. But if my memory serves me well, I had similar behaviour on a previous PC configuration (also with Opensuse and Gnome). I did not raise my voice earlier, because, well it is rather elusive and a bit sporadic, and I thought I had to mistrust my mouse first, and I tried to live with it. I also began to think that the problem got worse over time as more OS upgrades were installed, until after one upgrade, the problem seemed to disappear and then crept up on me again as time (and upgrades) went on. I do apologise for these vague observations, but under the circumstances, I am not really surprised that no-one else has spoken up either.
It can be frustrating when things don’t work reliably. A quick search turns up dozens of similar accounts, although most dealing with Windows and dodgy mouse switches. Even with hardware problems, some desktop environments provide mouse tuning utilities that include software de-bouncing. For example KDE has ‘Input Devices’ > ‘Mouse settings’ where the ‘double-click interval’ can be adjusted. Perhaps Gnome offers something similar eg gnome-tweak-took?
Anyway, the following advice from this Ubuntu thread is a good approach for testing
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.
This patch adds one configuration option, “DebounceDelay”, and one XInput
property, “Evdev Debounce Delay”. They refer to the amount of time to wait
after receiving a mouse button release event from the kernel before posting
the event to the X server. If a mouse button pressed event is received before
the delay expires, then the release/press pair is forgotten. This allows to
deal with mice whose button switches are worn out or dirty. Each mouse button
is debounced independently.
It’s really only a workaround though, as the mouse hardware should be doing the necessary in the first place