# Problem with mouse 'ghost' clicks in X windows? [SOLVED]

## adsicks

I have scoured I the Internet trying to fix a problem I have been having with ghost or bounce clicks causing fake double clicks in X windows for about a month. Most people wind up being convinced they have a hardware problem. Playing around with xev as well as a javascript mouse event page almost had me convinced. But as I was digging into the man pages I remembered I could just snoop the raw events with:

```
cat /dev/input/mice
```

After doing this I am convinced my hardware is fine. After several clicks, even some that caused bogus double clicks, I can confirm the were no extra clicks at that level of the driver.

Does anyone know of a workaround for th[/code]is problem?Last edited by adsicks on Wed Apr 20, 2016 7:44 am; edited 1 time in total

----------

## acmondor

Back in January I encountered a very similar problem and at first I could not believe it was a hardware issue. However, I eventually installed x11-apps/xev to monitor things and xev did eventually show that my mouse was generating the clicks (usually a double click when I pressed a button only once). So, I took it mouse apart, cleaned it and adjusted the button springs (required a careful dismantling of the buttons) and I'm happy to report that my 'ghost' click problem was cured. This mouse is used every day and it's been 'ghost' click free since the hardware tune up (about 3 months ago), so I definitely think your mouse could be the suspect.

----------

## adsicks

This is exactly what I thought too until I went down to the kernel level and looked at the garbage in:

```

cat /dev/input/mice
```

My mouse click made a distinct backspace in the garbage. clicking while watching /dev/input carefully produced random double click events in X and in a javascript test when the actually even shown in /dev/input/mice was dead on to my clicks and consistent.....

What do you trust, the kernel or X?

This is a brand new mouse....

My old ancient Logitech/Dell mouse works fine.

Maybe to really test it to be sure I can write a script that counts the times that ASCII shows up in that node?

----------

## Buffoon

Are you using evdev or mouse driver?

----------

## acmondor

 *adsicks wrote:*   

> This is exactly what I thought too until I went down to the kernel level and looked at the garbage in:
> 
> ```
> 
> cat /dev/input/mice
> ...

 

When I run:

```

cat /dev/input/mice
```

or this for more meaningful output:

```

cat /dev/input/mice | hexdump -C 
```

I only get output from mouse movements. Mouse clicks do nothing. To see the actual mouse clicks (and movement) from the kernel I did this (something I did not know back in January when I experienced the problem):

```

cat /dev/input/by-id/usb-055d_1031-event-mouse | hexdump -C
```

Note:

```

ls -l /dev/input/by-id/usb-055d_1031-event-mouse

lrwxrwxrwx 1 root root 9 Apr 17 10:34 /dev/input/by-id/usb-055d_1031-event-mouse -> ../event4
```

So this also works:

```

cat /dev/input/event4 | hexdump -C
```

I recently wrote some code to deal with joystick buttons and in the process I learnt that input devices like mice and joystick send out an event each time there is a change in the hardware (eg button press or movement). These events are what's encoded in the hex data displayed when using the above command.

As far as which I would trust (kernel or X), I would probably say the kernel, assuming the mouse doesn't require a new driver that may not be fully proven. I also personally wouldn't assume the brand new mouse is problem free, unless it has been proven to be so in another computer or with another OS.

----------

## acmondor

 *Buffoon wrote:*   

> Are you using evdev or mouse driver?

 

In my case it's evdev, even though both are installed. I confirmed that using this:

```
# ps -e | grep X

root      3128  3122  0 10:35 tty7     00:00:47 /usr/bin/X  ....

# lsof -p 3128 | grep -e evdev -e mouse

X       3128 root  mem       REG                8,3   100192    4994654 /usr/lib64/libevdev.so.2.1.10

X       3128 root  mem       REG                8,3    61088    4720453 /usr/lib64/xorg/modules/input/evdev_drv.so
```

----------

## MarioCorleone

A buddy and I have come to the conclusion that this has to do with synaptics.  He is running kubuntu with a synaptics touchpad, and I am running gentoo (obviously) E-0.20 with a synaptics clickpad.  We both noticed "sensitive" "erratic jumping"  "ghost double click" just extremely sensitive.  I recall an update about a month ago or so, and that is when this all started, I'm in the process of downgrading synaptics and will report back ASAP.

----------

## adsicks

I added "libinput keyboard mouse" to my INPUT_DEVICES (left synaptics and evdev in) and did a:

```
emerge -1av @x11-module-rebuild
```

and it is fixed.

Libinput support is in everything now due to Wayland I think is why....

I'm glad because I like my new mouse  :Smile: 

Notes:

I looked at it with hexdump -C also...

----------

