I see this also. I'm using Alt+1 ... Alt+4 to switch through the workspaces.

Workaround: Switch to text console (Ctrl + Alt + F1) and back to X (Alt + F7)
and the keyboard works again. 

However, very annoying indeed.
Oh.. one more thing.. while switching workspaces still works, entering text
doesn't. It's not just Gnome Terminal that's affected, other programs as well.

I noticed some more things: After the bug occurs (I can't type anything in xterm
for example) , I have to press the shortcut twice to switch screens. Also, the
"Redhat" Menu in the panel no longer opens when clicked.

Any progress on this? It's highly annoying.

I have not ever seen the bug, though I do use these shortcuts many times per
day. It may be some sort of race condition. Do people seeing it have especially
slow or fast machines, or machines under heavy load, or remote X connections?

None of the above really - I use Dell Inspiron 5000 Laptop - which is reasonbly
fast (P3 500) and all is local, i.e. no remote X connections. 
This problem never occured with 7.3 (gnome 1.4). 
I would say though that I'm a heavy shortcut user - i.e. I work a lot on web
development and typically have an editor open on one workspace and view results
with mozilla on another.
It seems very odd though that some keys still work whereas the others don't
(i.e. I can still ^Fx to switch workspaces but nothing else).
Is there something I could debug, etc. - I haven't seen anything useful in any
of the logs though...

You can start metacity as follows from a terminal:

METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity --replace

which will cause it to replace the current metacity instance and 
write a log file in /tmp. If you can then reproduce the lockup
(and ideally kill metacity while it's locked up, so I can see the right place in
the logfile) that might be helpful. (Or it may not be informative, but worth a try.)

Created attachment 80884 [details]
Metacity log file

OK, done - the whole file is attached.Sorry, it's quite big, but I couldn't
figure out which part is relevant.
All I did after the lockup is to switch to the console and killed metacity from
there, then copied the deug log file to metacity.log. I really hope this helps -
it's really hard to work without these shortcuts...

I'm also seeing this bug, though I didn't realize the connection to the
workspace switching until I read this here.

I use ALT-1..4 to switch between workspaces and occasionally nothing will
accept keyboard input (seemingly) except for Metacity.

It's not ALWAYS reproduceable for me (i.e, it doesn't happen every time I
switch workspaces), but it does happen fairly frequently (it happened while
submitting this comment, for example).

Computer is a Dell OptiPlex GXa (PII 333MHz)

Are you guys sure this problem is related to Metacity?  I'm seeing some other
ALT-key related bugs that indicate it may not.  Now whenever I hit the
right-side ALT key in console, it prints 0.. (see bug 74759) and after using
this key in X it starts printing "bbbbb" endlessly.  It didn't always do this,
and can be sorta fixed by unplugging the keyboard and plugging it back in.

The bad thing is that this is happening at my Dell computer at the office and on
my Athlon 750 system at home (which is running the null beta still).

The original bug still persists too sometimes.  Very strange stuff...  it may be
helpful to try and see if Metacity is in fact the culprit here.  Try sawfish and
see if the same problem pops up.  Could be a much lower level problem
considering the problems I'm seeing in the console even.

I doubt your problem is related to what I have reported - unplugging the
keyboard would suggest you have some kind of hardware problem. My right ALT key
here works just fine and besides I use CTRL and not ALT to switch workspaces.

Well, I don't believe it's a hardware problem.  I actually just checked and the
problem still persists after unplugging and replugging the keyboard (not sure
what happened before).

Plus, notice how I mention the exact same thing happens on two completely
different PCs that I use.  Check your right ALT key in console too.  I'm not
saying you'll see the same thing, because for awhile I was only experiencing the
lockup as mentioned originally in this bug.  But after this box has been up for
a few days I've noticed this new problem too.  Perhaps they're related, perhaps
not.  Just trying to gather data.

Just wanted to mention this lockup never happens when using the
CTRL+ALT+left/right or up/down key combinations. Havoc, did the log file reveal
anything - I'm really getting quite desperate.

I also see this problem. It seems to happen only on desktop switches with
redefined workspace shortcuts. I've got a 3x3 grid assigned to the num-pad keys.


One thing that always unlocks the keyboard is switching to an EMPTY workspace
and back. 

I'm running on a a 1200 athlon with a dual head display. Tried upgrading to tip
of XFree86 and metacity cvs but the problem persists.

Log file looks like metacity is getting key presses for the "a" key with no
modifiers. Did you press the "a" key, or is that just out of nowhere?

Metacity should not see presses of the "a" key with no modifier keys, unless 
you bind some WM function to it (seems unlikely).

Any usage of xmodmap etc. here?

It could be an XKB bug, or I remember some rumor that the kernel was being 
wonky about key handling, but I don't remember where I heard that.

It could also be related to the fact that keybindings don't work right if no
window is focused.

No 'a' key - to get the lock up i was doing fast CTRL-F1 and CTRL-F2. I haven't
setup anything in .xmodmap or similar - just plain clean RH80 install.
Focused windows: I would in general have a window focused on each of the screens
I am switching to/from (but probably not always).
There does not seem to be any rule of what kind of windows I have open - I think
the only possible rule would be that it takes sometimes a long time to trigger
this problem but as soon as it happens once it'll be happening almost on every
other switch.
I'll try sawfish just to make sure metacity really is the cause of this.

If you didn't press the 'a' key and metacity is getting key events for the 'a'
key, it's very likely to be some kind of X or kernel or hardware issue.

Maybe time for everyone to post which X driver they are using, and X/kernel
versions, to look for patterns there.

I'm using the stock kernel/XF86 packages that come with RH 8.0 (2.4.18-14, XF86
4.2.0-72), although the problem has been observed in the betas too (but not RH
7.3, note that I upgraded and did not do a fresh RH install).

I see the same problem on my computer at home and the one at work.  The one at
home is a custom Athlon box with a Matrox G400 MAX (mga chipset driver), and the
one at work is a Dell Optiplex (PII 333 with an ATI chipset card).  Both use the
legacy keyboard input driver.  Off the top of my head I can't think of any
significant common hardware between the two systems.

Two systems with the same problem here too. Both plain RH 8.0 with the latest
kernel (2.4.18-17.8.0). First system is Dell Inspiron 5000 with an ATI Rage
Mobility and the RH8.0 standard XFree package. 
The second system is Dell Inspiron 8200 which uses NVvidia Geforce 2GO card - I
have been running it with two different XFree drivers - one is using the set of
rpms from ftp://people.redhat.com/aoliva which are just RH8.0 rpms with this
card driver added in and the second is the NVidia official driver (problem
appears with both). I also never observed this problem on the 7.3 on either of
the two machines. I've just installed and am now running kernel 2.4.20-rc1 and
I'll report later if the problem happens with it or not.

I'm running on a 1200 AMD, XFree86 4.2.99.2 with a radeon 9000 pro in a dual head
setup. Kernel v2.4.18-14 (standard rh8.0). Tip of metacity CVS.

One additional observation, once this problem starts happening I can reproduce it
by changing from a workspace containing a bunch of overlapping xterms to a
workspace that contains evolution (v1.1.90 from ximian devel snapshot). Closing
or killev'ing evolution will release the keyboard (ie you can type again).

Hmm, I'm also using evolution and frequently switch between its workspace and
others.  I wonder if there's anything to that or not..  maybe not since I was
pretty sure that this problem was occuring on my other computer when I wasn't
running Evolution.

Problem still occurs fairly often, but I haven't been able to find a sure way to
reproduce it yet.

I've been running kernel 2.4.20-rc1 on the Inspiron 8200 machine since Saturday
and the problem has not happened so far. I'll try the same with the 5000 and if
the same is true there, I guess (at least on my systems) it's clear kernel is to
blame and not metacity. I wish I could prepare a clear testcase though - this
problem is really hard to trigger (once triggered though it happens very
frequently).

Just wanted to report that my other system also no longer has the problem after
changing the kernel to 2.4.20-rc1.

Kernels from rawhide also no longer have this problem (so far I tried 2.4.20-2.2
and 2.9).

I'm guessing same as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74635

That bug also has people whose problems were solved by kernel upgrade. 
Since the metacity log essentially makes no sense at all (given a working 
X/kernel), and several reports of fixage by kernel upgrade, I think it's pretty
likely this is a kernel thing solved in rawhide.

The bug still occurs with the latest RH8.0 kernel-2.4.18-19.8.0 so we still need
a fix (since more than 3 months...)

*** This bug has been marked as a duplicate of 74635 ***

If you are experiencing the problem reported in this bug report,
please read bug #76959 as it describes a similar problem.  I have
just added a patch to XFree86 which may fix that bug report, and
it's possible it may fix this one also.

If you find that it does fix the problem, please reassign this
bug to XFree86, and close as a duplicate of bug #76959.  Do the
same with any other similar bug reports you're aware of, if you
can confirm them as well.

TIA

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.