Bug 74760 - Using shortcuts for switching workspaces locks the keyboard
Summary: Using shortcuts for switching workspaces locks the keyboard
Status: CLOSED DUPLICATE of bug 74635
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: metacity (Show other bugs)
(Show other bugs)
Version: 8.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact:
Keywords: Triaged
Depends On:
Blocks: 79579
TreeView+ depends on / blocked
Reported: 2002-10-01 14:24 UTC by Need Real Name
Modified: 2007-04-18 16:46 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 18:49:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Metacity log file (1.32 MB, text/plain)
2002-10-17 22:55 UTC, Bostjan Lah
no flags Details

Description Need Real Name 2002-10-01 14:24:46 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020918

Description of problem:
I use CTRL+F1..4 to switch workspaces in Gnome (using the standard setup with
Metacity, etc.). When switching using these assigned shortcuts the keyboard
seems to lock up - in the window on the workspace I switched to   I am unable to
type anything. The switching of workspaces still works and with a few more
CTRL-F? switches the keyboard resumes working.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Assign shortcuts ^F1..^F4 to switch to workspace 1..4
2.Switch several times quickly between two workspaces
3.Try typing something in the Gnome Terminal

Actual Results:  Nothing can be typed in the Gnome Terminal

Expected Results:  Keyboard working as expected

Additional info:

Comment 1 Sven Neuhaus 2002-10-02 09:25:08 UTC
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.

Comment 2 Sven Neuhaus 2002-10-02 09:35:50 UTC
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.

Comment 3 Sven Neuhaus 2002-10-17 09:03:07 UTC
Any progress on this? It's highly annoying.

Comment 4 Havoc Pennington 2002-10-17 20:54:29 UTC
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?

Comment 5 Need Real Name 2002-10-17 21:28:59 UTC
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...

Comment 6 Havoc Pennington 2002-10-17 22:14:59 UTC
You can start metacity as follows from a terminal:


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.)

Comment 7 Bostjan Lah 2002-10-17 22:55:15 UTC
Created attachment 80884 [details]
Metacity log file

Comment 8 Bostjan Lah 2002-10-17 22:55:37 UTC
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...

Comment 9 Nathaniel Case 2002-10-18 20:13:41 UTC
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)

Comment 10 Nathaniel Case 2002-10-21 01:13:59 UTC
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.

Comment 11 Bostjan Lah 2002-10-21 03:03:09 UTC
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.

Comment 12 Nathaniel Case 2002-10-21 03:10:05 UTC
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.

Comment 13 Need Real Name 2002-11-07 14:42:03 UTC
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.

Comment 14 Maciek Klimkowski 2002-11-08 21:11:10 UTC
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.

Comment 15 Havoc Pennington 2002-11-08 21:46:08 UTC
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.

Comment 16 Need Real Name 2002-11-08 22:08:33 UTC
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.

Comment 17 Havoc Pennington 2002-11-08 22:20:25 UTC
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.

Comment 18 Nathaniel Case 2002-11-10 02:22:55 UTC
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.

Comment 19 Need Real Name 2002-11-10 03:14:01 UTC
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.

Comment 20 Maciek Klimkowski 2002-11-11 13:26:53 UTC
I'm running on a 1200 AMD, XFree86 with a radeon 9000 pro in a dual head
setup. Kernel v2.4.18-14 (standard rh8.0). Tip of metacity CVS.

Comment 21 Maciek Klimkowski 2002-11-11 13:29:55 UTC
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).

Comment 22 Nathaniel Case 2002-11-11 18:20:13 UTC
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.

Comment 23 Need Real Name 2002-11-11 21:57:39 UTC
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

Comment 24 Need Real Name 2002-11-15 14:00:15 UTC
Just wanted to report that my other system also no longer has the problem after
changing the kernel to 2.4.20-rc1.

Comment 25 Need Real Name 2003-01-10 15:28:25 UTC
Kernels from rawhide also no longer have this problem (so far I tried 2.4.20-2.2
and 2.9).

Comment 26 Havoc Pennington 2003-01-14 21:50:07 UTC
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.

Comment 27 Sven Neuhaus 2003-01-15 10:35:12 UTC
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...)

Comment 28 Havoc Pennington 2003-01-15 14:17:47 UTC

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

Comment 29 Mike A. Harris 2003-12-18 17:00:45 UTC
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.


Comment 30 Red Hat Bugzilla 2006-02-21 18:49:42 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.