Warning: this is going to be a long story with a semi-happy ending. Skip it unless you enjoy tales of woe and debugging.

So, I open up my laptop, plug in a USB keyboard and mouse, start up Inkscape and start fooling around. Suddenly I notice strange behaviour:

  • I cannot select two objects in Inkscape by holding down ctrl or shift and clicking -- only the last object I clicked on becomes selected.
  • Menus don't pull down, although the highlighted bar follows my mouse
  • I cannot type any text into text boxes
  • Moving the mouse into a screen corner doesn't trigger the Expose-like effect
  • I cannot drag windows around by grabbing the title-bar
  • I cannot drag windows around by alt+dragging
  • Dragging the mouse inside an xterm creates a vertical selection

That last hint seems to indicate that the Ctrl key could be stuck. I try pressing it and releasing, then the other one, then both Ctrl keys on the USB keyboard. Surely, if X sees a press and a release event for each Ctrl it will realize none of them are still down? No such luck. I try to unplug the USB keyboard and mouse next. No results.

This is not the first time this has happened to me. Previously I found no exit out of this state other than killing X.org with (great pleasure and) Ctrl+Alt+Backspace. Surely there must be a better way?

I ssh in and start xev. MotionNotify events have state 0x4, which is control, I think. By the way, I only see mouse events in xev, keyboard events don't make it. The keyboard itself is alive at some level, as Caps Lock turns on its LED, and Ctrl+Alt+F1 gives me a (garbled and unusable) text console. Holding down Alt or Shift doesn't change the state of events seen by xev, though.

Did my keyboard map get lost? Is some X client grabbing all the keys? how do I recover?

I use x2x to connect to the laptop from my desktop. I now can use my desktop's mouse and keyboard to control the laptop. x2x works by injecting X events via XTest. I see mouse events x2x injects, but xev again shows nothing on the keyboard front.

I try to guess which X client might have the keyboard grab (if there is one). I killall compiz. I'm surprised that gnome-session doesn't restart it (or spawn a different window manager in its place). I start metacity manually. The problem is not gone. I kill metacity and start Compiz again.

I have a VNC server running (vino), but I've forgotten its password.

I notice a weird message in my xev log:

KeymapNotify event, serial 40, synthetic NO, window 0x0,
    keys:  4294967195 0   0   0   32  0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

Huh? 4294967195 keys? That looks like an unsigned 32-bit int underflow. I scroll back and find the first KeymapNotify event seen by xev:

KeymapNotify event, serial 25, synthetic NO, window 0x0,
    keys:  0   0   0   0   32  0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

Looks normal. Then I notice this at the end of the xev log:

FocusOut event, serial 40, synthetic NO, window 0x3e00001,
    mode NotifyWhileGrabbed, detail NotifyNonlinear

What's "NotifyWhileGrabbed" mean? How do I find the rogue app and kill it? xrestop shows me 35 X clients, do I just kill them one-by-one until the problem disappears? Some of those clients are <unknown> and show no PID.

I suspend the laptop (which is a very stupid idea when your other machine's mouse and keyboard are redirected to it via x2x) and resume it, hoping that gnome-screensaver will somehow overpower the existing application's lock with its own. Gnome-screensaver is nowhere in sight. At least my x2x connection becomes alive again and I have my keyboard & mouse back on the desktop.

I notice that I can no longer make any kinds of selections in gnome-terminal. Why? Window focus no longer follows mouse. xev no longer sees mouse motion events. It sees a couple of MappingNotify events when I plug in a (different) USB keyboard, though.

I killall gnome-screensaver (which was invisible, remember?) and can now again see motion events in xev and select windows with the mouse.

I start randomly killing applications. gnome-power-manager. nautilus. inkscape. firefox. gtk-window-decorator. gnome-panel. notification-daemon. gnome-terminal. pulseaudio (no reason). vino-server. update-notifier. seahorse-agent. gnome-keyring-daemon. bluetooth-applet. fast-user-switch-applet. multiload-applet-2. mixer_applet2. system-config-printer. gnome-settings-daemon.

And the system becomes ugly (no GNOME theme) but alive. I get a second xev window from an earlier attempt to type 'xev' in a terminal that was unable to receive key events.

Of course, since I killed all the actual applications and half of the necessary support programs my session is now useless, so I'll have to log out and log back in again. But at least in the future I'll know: when something like this goes wrong, killall gnome-settings-daemon.

Now I'd like to report a bug (the thought of hurling a brick through the responsible developer's window never crossed my mind, honest!), but without a reliable way of reproducing the problem will it be of any use?

I restart gnome-settings-daemon and it promptly invokes xrandr to set up a dual-head mode that confuses compiz. By "confuses" I mean displays a rotating cube in the top-left 1280x700 area of my 2560x1024 extended desktop, filling the rest with whatever was in the video memory last time I had a dual-head mode.

I try to start up Firefox on my desktop and put a link to the relevant bug, but Firefox quietly refuses to start up. Well, 'Segmentation fault' at the end of ~/.xsession-errors is quiet, isn't it? Thankfully, 'firefox http://someurl' for some reason works and opens a window. I cannot find the Compiz bug I remember (could it have been #135418?), but this looks like a better fit anyway: #317431 (and #206998 might be a duplicate). And here's my gnome-settings-daemon bug: #335201.

This is all on Ubuntu 8.10 (Intrepid Ibex).

Some days I just hate Linux. Then I remember that it's worse on other systems...