Bug 16639

(In reply to M K from comment #0)
> I think since update of x11 package (#16182) the mouse driver sends
> sometimes doubleclicks instead of single clicks.
> 
> I encounter this behaviour the last few days - this was not the case on
> release.
> 
> What I encounter is, sometimes I click, and a few seconds (!) later again,
> and I get a doubleclick.
> I use LXDE/openbox, but I've already tested mate, where I get the same
> behaviour.
> 
> This is really annoying, since marking text, clicking, ... is only working
> sometimes.
> 
> Can you give me a hint, where I can look for this?!
> 

CC'ing LXDE & Mate maintainers, who might be able to reproduce & have a clue what's going on

CC: (none) => loginov_alex, marja11, nicolas.salguero, tarakbumba
Summary: doubleclick instead of single click => single clicking & waiting a few seconds & then single clicking again, sometimes results in a double click

Most GUIs, including I think xorg, have a setting that determines how close together two clicks must be to count as a double-click.  This is probably another example of upstream changing some default to something nobody expects.

CC: (none) => ftg

For me thi doesn't look like two clicks are too close together (since this would be reproduceable) - it's more like the first button press (or release event) sometimes get's handled twice (the state was not released).
I tried to check this with xev - but I had no luck, since I can't reproduce it reliably, so the output didn't help.

I'll so some more tests tomorrow - thanks so far.

ok, tested some more with xev - the button is really fired twice, but only pressed once:
ButtonPress event, serial 45, synthetic NO, window 0x3800001,
    root 0xf6, subw 0x0, time 1186873, (94,142), root:(95,164),
    state 0x10, button 1, same_screen YES

ButtonRelease event, serial 45, synthetic NO, window 0x3800001,
    root 0xf6, subw 0x0, time 1186945, (94,142), root:(95,164),
    state 0x110, button 1, same_screen YES

ButtonPress event, serial 45, synthetic NO, window 0x3800001,
    root 0xf6, subw 0x0, time 1186953, (94,142), root:(95,164),
    state 0x10, button 1, same_screen YES

ButtonRelease event, serial 45, synthetic NO, window 0x3800001,
    root 0xf6, subw 0x0, time 1186993, (94,142), root:(95,164),
    state 0x110, button 1, same_screen YES

The second Press is fired right after the release is done (which I can see if I "mark text in xev").
8ms between these clicks looks like an debouncing issue.

I'm note sure if this might be related:
"usb 1-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes"

As far as I can see (http://blog.guntram.de/?p=16) there is no debouncing option in evdev and even there is no default set (to 20ms) - which is bad too.

drakconf doesn't set any mouse other than evdev (no setting saved) - i think the old "MS mouse" option had a debouncing set.

I tried switching to the old "mouse" driver in X, but this is even worse - the mousecursor moves uncontrollable on the screen.

there are patches available for evdev:
https://aur.archlinux.org/packages/xf86-input-evdev-debounce/
I don't see why this is not integrated, since software debouncing is quite common on switches.

I don't know who is responsible for the debouncing of the switches (kernel, xorg, lxde) but sth. must have changed - the mouse has worked before and accepting clicks in intervals less than 20ms is never reasonable.

Just out of curiosity, can you reproduce this on any other hardware ?  Or do you have older software which works correctly on this hardware ?  Either would help remove some change/damage to your mouse as the cause of the problem.

hmm, you're right looks like the button of this mouse bounces.
So this is just a coincident with the update - or both.
I have to check if I have older software - but I think they're all up-to-date.

But I still wonder why there is no debouncing option.

Sorry to steal your time.
It was really the left mouse button which bounces. It was just a coincident to the package updates, so I didn't think of the mouse button itself.

Status: NEW => RESOLVED
Resolution: (none) => INVALID

@ M K

No problem, thanks for telling us and for closing the bug accordingly :-)

@ Frank

Thx for your help in this and other bug reports!