Red Hat Bugzilla – Bug 407201
X.org eating 30% of cpu when moving my mouse
Last modified: 2008-07-21 20:12:35 EDT
Description of problem:
When I happen to move my mouse, X.org eats between 30 to 40% of the CPU time.
My mouse is a Logitech G5 Laser mouse.
I tested on two computer, a laptop and a desktop one.
Laptop : Sempron 3100+, 1,5go of RAM, ATI proprietary drivers.
Desktop : Athlon 2800+, 1go of RAM, nVidia proprietary drivers.
I alwso tested on both machine under Fedora 7 and the problem does is not present.
Please tell me all the extra info you would need to fix the bug.
Created attachment 274641 [details]
screenshot of gnome-system-monitor
I tested with a cheap mouse and I don't have the problem. Maybe the bug is on
evdev and not xorg-x11-drv-mouse ?
I have a bad news for you -- we really need you to reproduce this without using
proprietary drivers -- we have a long list of issues which evaporated just when
user switched to open source drivers (that's nothing to say against ATI and
nVidia engineers -- they have certainly similar list of problems caused by our
drivers, but we really cannot diagnose the problem in those drivers).
In order to clean your computer of all remains of those drivers, please follow
steps on http://fedoraproject.org/wiki/Xorg/3rdPartyVideoDrivers.
Then please attach your X server config file (/etc/X11/xorg.conf) and X server
log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 293464 [details]
xorg.conf after fresh install
Created attachment 293465 [details]
xorg log file after fresh install
Created attachment 293466 [details]
xorg log file after redetecting my hardware
Here are all the files you asked for. Thank you very much guiding me through
this bug. I made a fresh install of Fedora 8 and did not update it yet. However,
on the old installed one, the problem is still there so I guess update will not
fix the issue. But i will made them, one never knows.
After restarting without xorg.org file, the system did not detect anything and
failed starting. I had to start system-config-display, which made X start
successfully and validate the default configuration it found.
The bug is still present in a today updated rawhide (fresh fedora 9 alpha that
update regularly). I did not install any proprietary driver on it. Do you need
more information ?
what version are you running now, and is this still an issue?
Also, can you give me a log file of your current server please, if you switched
to F9 then you also bumped the server version.
Hello Peter and thanks to take back this bug :)
I have 2 pcs on which the problem occurs with the same mouse
Both PC are running Fedora 9 and are up to date. Both did not received any video
proprietary drivers. One is nvidia video card, the other is ati video card. Both
are AMD processor.
Here are the xorg rpm installed related to pointing devices :
I post the xorg.log below.
Created attachment 312199 [details]
worg log file (peter request)
can't see anything in the log files that'd be out of the ordinary.
Looking at the specs - this mouse has a high reporting rate, so the load may be
due to the high sample rate.
for example, a cheap mouse may report 5 move events by 10/10 each.
this mouse with its higher sample rate may report 50 events by 1/1 each instead.
This could contribute to the high load. it would also explain why you only see
it when you move the mouse.
please connect a different mouse to the same box and restart X. If it only
happens for the laser mouse, then its hardware related.
However this happened only from Fedora 8. It worked normaly under Fedora 7.
OK forget it I have the same load under Windows... damn :( I need to buy a new
This is just a random guess but F7's server may have used polling for the mouse
instead of SIGIOs. In this case the data would accumulate and result in less
events - and less load. Just a guess though.
Anyway, closing as NOTABUG, it's HW related.