* David MartÃnez Moreno
> I think that you could use xev in order to know if X.Org is receiving
> input:
>
> I am supposing you are "capable" of making the failure happen quickly
> (more or less).
>
> First launch a terminal and a browser in the same desktop. Then use
> xwininfo in order to obtain the ID of the browser. Then launch xev -id
> WINDOW_ID in the terminal and feel free to surf. As you will see, xev
> intercepts *every* event belonging to the window (key presses, mouse
> movements, etc.). When it happens, you can tell us if you start to
> lack output in the xev terminal. If so, I would guess for a kernel
> problem. If not...well, we could try another thing. :-)
I thought of this a few minutes after writing my original report, but
obviously forgot to follow up with my results. I'm at work now, so
this is from memory, but what I did was something like this (when the
breakage happened):
1) Change to another VT (with the help of Alt+SysRq+R).
2) From there start DISPLAY=:0 xev
3) Change back to the VT with X, where xev now is visible and has
input focus according to my window manager
And then batter the keyboard, move the pointer around, hit mouse
buttons, and so on, and change back to the VT where xev was started to
inspect the output. The result: No MotionNotify, KeyPress/Release, or
ButtonPress/Release events at all. The only ones were some Expose and
Visibility*-events (can't quite remember the order of them, though).
I'm using focus-follows-pointer, but the focus do not change from the
xev window when I move the pointer to some other window, so the window
manager appears to be oblivious to the MotionNotify-events too. It
seems as if the X server simply stops sending those events.
It might of course be a kernel bug - I did indeed upgrade to 2.6.16
recently. I can try downgrading to 2.6.15 and see if I experience the
bug then. The X server is my prime suspect though - the keyboard works
perfectly on the console, and I need only restart X to fix the problem.
I will install GPM to see if the mouse continues working fine on the
console when X has problems.
One thing that really makes me think the kernel is unlikely, is the
fact that the pointer actually moves around the screen when I move the
mouse, so the X server has to receive the events from the kernel orelse
the pointer would appear to be stuck/frozen, no? Yet there's no
MotionNotify-events - I assume the kernel doesn't have anything to do
with generating those?
I will attach an xev to my browser like you suggested and see if I get
the same results. However I'm unable to reproduce it at will, it just
happens once in a while - and I can't guarantee that I will be
browsing when it happens. I'll try (from the console) to attach xev to
whatever window had focus if that happens, though. I guess I can use
xwininfo -name to get the window ID without having to rely on the mouse
working, so that should be no problem.
Another thing I just thought of and I'll try is to remove all the USB-
related modules and re-insert them again, to see if that will fix the
problem without requiring a restart. Both my keyboard and my mouse
are USB devices. I did try hotplugging them though, without any
success.
Kind regards
--
Tore Anderson
