Red Hat Bugzilla – Bug 56411
Mouse moves, focus gets locked. Click ineffective, alt-tab works.
Last modified: 2007-04-18 12:38:20 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686)
Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Sometimes I can't switch the window focus using the mouse. The mouse
The button clicks. But the window focus does not change. I can only type
the current window. Usually I have to kill X to get back in good shape.
Sometimes I get a partial change of focus in netscape. I'll clearly click
into a dialog box (the title bar changes), but all characters typed go into
the previous focus (such as the URL bar).
In all cases using ALT-TAB will change the focus.
Actual Results: Linux should not be as flakey as Windows.
I have had similar issues, but only on my IBM laptop. I can not reproduce the
problem on my desktops/servers. To make it even weirder, it only seems to happen
when I am on battery... I am not a newbie, and it does not make sence to me
either, but I figured I should mention it.
I also tried to use enlightenment as the underlying WM, and still had the issue.
I have als tried telling nautilus not to draw the desktop, and still the problem
The problem can be ellicited by opening two gnome-terminals and placing them
side-by-side. Then moving the mouse between them. At random times (usually one
out of 15-20 or so), the one that should be focused is not, and the only way to
give it focus is to move out of the window and back in, or click the title bar.
This also happened with RadHat 7.1 and Ximian.
I think I have found the problem on my A21P IBM Thinkpad...
It has to do with speedsteping which is present on some laptops to slowdown
the processor when on battery to minimize power drain. When the laptop is
plugged in, focus works fine, but when I am on battery I see focus bugs on
several differnt window managers (Sawfish and KDE for example). Disabling the
speedstep in BIOS seemed to have solved the problem for me.
I believe this was causing the problem because the gettimeofday C function may
not be returning the correct time if the CPU has changed speed since boot.
Focus grabs depending on the WM may be dependant on this (to the best of my
knowledge). I read something similiar on a KDE list.
There is also a kernel boot option "notsc", but that did not seem to help me.
Hopefully the kernel will be able to address variable CPU speeds in the near
There is a thread on the kernel mailing list regarding this starting at
I have just completed a text mode interface for redhat-config-mouse, which means
that mouseconfig will be deprecated in the next release of Red Hat Linux.
Therefore, I will not be putting any development time towards fixing mouseconfig
bugs, so I'm closing this as 'wontfix'.
Errr.... how is this a mouseconfig issue if it happens under X with a working mouse?
Sorry, this was originally filed against mouseconfig. The message attached
above happened when I modified all open mouseconfig bugs, and this report was
affected. I'm not sure exactly what the problem is that you are seeing.
Perhaps it's a window manager problem, but perhaps it's an X problem.
I'm assigning it to X to see if mharris has seen this behavior before.
This isn't an X problem. A window manager problem perhaps, but not an
X problem. I don't know what window manager is being used, so I'm
reassigning it back to the original component it was filed against.
Sigh. I don't know what else to do besides close this as 'worksforme'. We
haven't been able to reproduce this on any of our test machines.