Keeping usb mouse buttons pressed results in repeated ButtonPress events [regression]

Bug #223278 reported by mikbini
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Invalid
Undecided
Unassigned
Declined for Hardy by Timo Aaltonen
Nominated for Intrepid by mati
Nominated for Jaunty by mati
xorg (Ubuntu)
Invalid
Undecided
Unassigned
Declined for Hardy by Timo Aaltonen
Nominated for Intrepid by mati
Nominated for Jaunty by mati
xserver-xorg-input-evdev (Ubuntu)
Invalid
Undecided
Unassigned
Declined for Hardy by Timo Aaltonen
Nominated for Intrepid by mati
Nominated for Jaunty by mati

Bug Description

Binary package hint: xserver-xorg-input-evdev

I just updated a 7.10 installation to 8.04 and I tried both workarounds described in bug #173833 (placing 10-x11-input.fdi in /etc/hal/policy/ and manually setting the path to the device special file) to make it work.

With either one of them the mouse works, sort of. The problem is that if I keep a mouse button pressed it repeatedly generates ButtonPress events until I release it.

This makes the system almost unusable as most (all?) programs interpret these repeated ButtonPress-es as multiple clicks and thus:

 * when I drag windows they maximize, then minimize maximize again, etc
 * when I drag nautilus file or folders icons I instead draw fancy frames (the area-selection boxes)
 * when I select something if I am not quick I instead double click it
 * I cannot select stuff in xterm (the selection keeps resetting as I drag the mouse)

These are only examples of the many, many problems this bug causes: almost nothing is usable. Please also note that on the console gpm works correctly.

I'm attaching the relevant part of an xev log (but I don't think it wolud really help): I obtained it by pressing the left mouse button, waiting a handful of seconds and then releasing it.

I'm using a MightyMouse but it doesn't seem specific to this mouse (see my comment #2 below)

Finally note that it worked correctly with 7.10 and thus this is a regression.

Tags: hardy
Revision history for this message
mikbini (mikbini) wrote :
description: updated
Revision history for this message
mikbini (mikbini) wrote :

After further investigation I found that it is not Mighty Mouse specific but may happen with any USB mouse using the evdev driver (I'll change the description) and that even Mark Lord himself was hit:

http://kerneltrap.org/mailarchive/linux-kernel/2007/12/2/468128

alas no suggestion nor conclusion about it, except that it might be specific to linux kernel 2.6.24. What's worse: a reboot solved the issue for Mark Lord but for me it doesn't :(

Revision history for this message
mikbini (mikbini) wrote :

Reassigned as it is apparently due to evdev

description: updated
Revision history for this message
mikbini (mikbini) wrote :

I suspect there are actually *two* mouse configured in X11. I'm attaching the output of "xinput list" which shows my hand-configured "MightyMouse" and also a mysterious "Macintosh mouse button emulation", uhm...

Revision history for this message
mikbini (mikbini) wrote :

Adding

Option "AutoAddDevices" "false"

to the ServerFlags section in xorg.conf gets rid of "Macintosh mouse button emulation" but the multiple clicks stay :(

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

The events come from the kernel, so it's probably a bug there. Anyway, cannot reproduce on Intrepid, so closing as fixed.

Changed in xorg:
status: New → Invalid
Changed in xserver-xorg-input-evdev:
status: New → Fix Released
Revision history for this message
Mark Smith (smitty1smitty) wrote :

This bug is still present in Hardy Heron (8.04). Since it has to do with a user's ability to use mouse input with evdev, and Hardy is LTS, I nominate it to be repaired in Hardy as well.

Revision history for this message
Bryce Harrington (bryce) wrote :

Hi mikbini,

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with the latest development release of Ubuntu? (ISOs are available from cdimage.ubuntu.com)

If it remains an issue, could you also attach a new /var/log/Xorg.0.log?
Thanks in advance.

The output of lspci -vvnn would also be worth having.

Changed in xserver-xorg-input-evdev:
status: New → Incomplete
Revision history for this message
personman (personman-145) wrote :

I've recently experienced this problem in Debian after upgrading to xorg 1.5.x and switching the mouse to the evdev driver. I've been able to correct the issue by removing the package, "xserver-xorg-input-mouse"

Revision history for this message
mati (mati-wroc) wrote :

Reopening, as it still happens in an up-to-date Intrepid. My mouse (Logitech MX610, USB one, no adapter) works fine, as I had no problems in Windows.

It's very difficult to move any scroll bars, drag the windows on the screen or to select any text. It's very annoying and productivity-killing :( I would provide any help to debug this.

Changed in linux:
status: Fix Released → Confirmed
Revision history for this message
mati (mati-wroc) wrote :

Another symptom:
Sometimes clicking with left/middle button at some point on the screen results in the click being fired at completely different point. Following clicks appears at exactly same point. Only pressing right button resets this state and allows to make the right click.

Revision history for this message
Abu Bakar Al-Idrus (alidrus2000) wrote :

As of right now, I still am having this problem in Intrepid Ibex. I believe the problem began some time in December 2008 upon installing some updates. My laptop which has Hardy Heron seems to be ok and is not affected by this bug. Is there anyone who can offer a workaround for this problem? It's driving me nuts.

Revision history for this message
mati (mati-wroc) wrote :

Seems like additional events was a result of a mouse, as described here: http://forums.logitech.com/logitech/board/message?board.id=hardware_mice&thread.id=3406
Logitech has replaced my faulty MX610 for a new MX620 and everything seems to be fine so far :)

Bryce Harrington (bryce)
Changed in xserver-xorg-input-evdev (Ubuntu):
status: Incomplete → Confirmed
Bryce Harrington (bryce)
tags: added: hardy
Revision history for this message
romke (rombar) wrote :

Same here, attaching xev log file. During test I pressed right button hold it for few seconds and released. I did this ONCE but as you can see in log is several Press/Release events.

Revision history for this message
romke (rombar) wrote :

I can confirm that this is HARDWARE ISSUE caused by FAULTY mouse button. Support request from Logitech was resolved by fixing faulty mouse and now everything is fine.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Thanks, closing the bug.

Changed in linux (Ubuntu):
status: Confirmed → Invalid
Changed in xserver-xorg-input-evdev (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Sorry, it wasn't the original submitter who said this was a hw issue..

Changed in linux (Ubuntu):
status: Invalid → New
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Closing anyway. mkbini, if you can reproduce the issue on 9.10 or lucid, feel free to reopen. Updates to the evdev driver in 8.04 are not going to happen.

Changed in linux (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.