Bug#364288: Randomly loses input since X11R7 upgrade

[Tore Anderson <tore@debian.org>]

* 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