Left mouse click not completed in timely manner
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Invalid
|
Medium
|
Unassigned |
Bug Description
I am running 10.4 which was upgraded directly from an up-to-date 8.04. This problem did not exist in 8.04.
When selecting anything that requires a single mouse click (item from drop down menu; icon in panel; button in dialog; etc.)
the response -may- be delayed (for some considerable time, as much as 9 seconds). During this delay, any mouse action
such as a mouse move will cause the action to be performed. As a secondary issue, and I believe these two are related,
when scrolling vertically in a window using the mouse, sometimes the single mouse click is processed as a double click (that
is, instead of scrolling one page, two pages are scrolled).
To aid you in finding this bug, I have done some additional testing which I will describe below. But first,
I have a Logitech keyboard/mouse combination (MX 3200) which is wireless and USB connected. I have borrowed a
keyboard/mouse combination (same make and model) that works fine on a Windows system, and I get the same type problem
on my system with that mouse. In addition, my mouse works fine on the Windows system.
Now for my testing. I have modified the program 'xev' to add an output line to the ButtonRelease data. It can be identified as
'diff xxxx <<<<' where xxxx is the time between when xev receives the ButtonPress event and the ButtonRelease event, in
milliseconds. Here is an example of the output from the modified xev program.
-------
ButtonPress event, serial 30, synthetic NO, window 0x4000001,
root 0x117, subw 0x0, time 19405714, (132,33), root:(312,573),
state 0x10, button 1, same_screen YES
ButtonRelease event, serial 30, synthetic NO, window 0x4000001,
root 0x117, subw 0x0, time 19405848, (132,33), root:(312,573),
state 0x110, button 1, same_screen YES
diff 177 <<<<
ButtonPress event, serial 30, synthetic NO, window 0x4000001,
root 0x117, subw 0x0, time 19407234, (132,33), root:(312,573),
state 0x10, button 1, same_screen YES
ButtonRelease event, serial 30, synthetic NO, window 0x4000001,
root 0x117, subw 0x0, time 19407384, (132,33), root:(312,573),
state 0x110, button 1, same_screen YES
diff 149 <<<<
ButtonPress event, serial 30, synthetic NO, window 0x4000001,
root 0x117, subw 0x0, time 19408738, (132,33), root:(312,573),
state 0x10, button 1, same_screen YES
ButtonRelease event, serial 30, synthetic NO, window 0x4000001,
root 0x117, subw 0x0, time 19408856, (132,33), root:(312,573),
state 0x110, button 1, same_screen YES
diff 2269 <<<<
MotionNotify event, serial 30, synthetic NO, window 0x4000001,
root 0x117, subw 0x0, time 19411008, (132,34), root:(312,574),
state 0x10, is_hint 0, same_screen YES
MotionNotify event, serial 30, synthetic NO, window 0x4000001,
root 0x117, subw 0x0, time 19411064, (132,35), root:(312,575),
state 0x10, is_hint 0, same_screen YES
-------
In the first two ButtonPress/Release events, the difference in the event times as reported in the output is consistent with the
time difference that xev sees (177 milliseconds and 149 milliseconds).
But in the third ButtonPress/Release event, while the difference in the event times as reported in the output (118 milliseconds)
is consistent with the other two, xev didn't see the ButtonRelease data for 2269 milliseconds, and then only because I moved
the mouse.
To me, this would indicate that the release of the mouse button is seen by the system when it happens, but for some reason, it
is not reported back when asked for. Also, if I had not moved the mouse, after some varying amount of time, the ButtonRelease
would have been given to xev, as if something was awakened by a timer expiring.
Also note that if some other application that consumes some significant amount of system resources (such as System Monitor/
Resources) is running, this problem does not occur (or at least with the testing I did).
While I am not a linux guru, I will be glad to provide other information, if you tell me how to get it.
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: linux-image-
Regression: Yes
Reproducible: Yes
ProcVersionSign
Uname: Linux 2.6.32-23-generic i686
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.21.
Architecture: i386
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
Card hw:0 'Intel'/'HDA Intel at 0xe0320000 irq 22'
Mixer name : 'Realtek ALC1200'
Components : 'HDA:10ec0888,
Controls : 28
Simple ctrls : 17
Date: Sat Jul 10 13:38:46 2010
HibernationDevice: RESUME=
IwConfig:
lo no wireless extensions.
eth0 no wireless extensions.
ProcCmdLine: root=UUID=
ProcEnviron:
LANG=en_US.utf8
SHELL=/bin/bash
RelatedPackageV
RfKill:
SourcePackage: linux
WifiSyslog:
dmi.bios.date: 02/03/2009
dmi.bios.vendor: Intel Corp.
dmi.bios.version: ECG3510M.
dmi.board.
dmi.board.name: DG35EC
dmi.board.vendor: Intel Corporation
dmi.board.version: AAE29266-209
dmi.chassis.type: 3
dmi.modalias: dmi:bvnIntelCor
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
tags: | removed: regression-potential |
Richard Olsen, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please plug in the USB mouse that demonstrates this problem, unplug all other USB devices, execute the following via a terminal and post the results to this report:
lsusb
As well, does this happen in Ubuntu with a different USB mouse or just this one?
In addition, could you please provide the information following https:/ /wiki.ubuntu. com/DebuggingMo useDetection# In_case_ some_mouse_ buttons_ or_scrollwheels _don.27t_ work_.28as_ expected. 29 ?
Also, could you please test for this with the latest development release of Ubuntu? ISO CD images are available from http:// cdimage. ubuntu. com/releases/ .
If it remains an issue, could you please run the following command in the development release from a Terminal (Applications- >Accessories- >Terminal) , as it will automatically gather and attach updated debug information to this report:
apport-collect -p linux <replace- with-bug- number>
Also, could you please test the latest upstream kernel available following https:/ /wiki.ubuntu. com/KernelMainl ineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested and remove the tag: testing
needs-upstream-
This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the text: testing
needs-upstream-
If this bug is fixed in the mainline kernel, please add the following tags: fixed-upstream fixed-upstream- VERSION- NUMBER
kernel-
kernel-
where VERSION-NUMBER is the version number of the kernel you tested.
If the mainline kernel does not fix this bug, please add the following tags: bug-exists- upstream bug-exists- upstream- VERSION- NUMBER
kernel-
kernel-
If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags: unable- to-test- upstream unable- to-test- upstream- VERSION- NUMBER
kernel-
kernel-
Please let us know your results. Thank you for your understanding.