For more relevant details (specifically the last few comments), see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=259740.

There's been a problem for some time with the 4.3.0.dfsg.1-6 xlibs package in
debian that breaks Alt-tab, among other things.  I've been telling users to
downgrade to 4.3.0.dfsg.1-4, which is what I've done on my personal workstation.
 From reading those bug reports, it looks like the problem is in the XKB
configuration, and I don't see anywhere a solution for how the window manager
can get around the problem.

What changes need to be made to metacity?

I don't really understand this; the way I read the fd.org bug 580, metacity
should not be affected, look at the code for keycode_is_primary_modifier() and
the handling of KeyRelease in keybindings.c

Ross I'd suggest looking at some verbose debug spew from metacity, maybe adding
some of your own, and see exactly what is happening that leads to the stuck popup.

One more data point I forgot to mention is that when I go to Keyboard Shortcuts
and try and define (say) Super-F as the binding for an action, the applet thinks
that Super is a real key and not a modifier and puts "Super_L" in the binding.

I'll poke with metacity in debug mode later today.

So much for Rob's comment in bug 142947 that the solution was to just use
Debian.  ;-)

I've ran metacity in verbose mode and got some logs of me doing super-up (in the
top left workspace so no workspace is switched) in both the "broken" keymap
(log-broken) and after running "xmodmap -e 'clear mod4' -e 'add mod4 = Super_L'"
(log-working).

Note that in the broken log the key release doesn't cause the popup to go until
I re-press Super, which is logged as a "uninteresting" event and causes the
popup to die.

Also note that I cannot bind any keystroke involving <Super> in the keybinding
properties as it believes I have finished pressing keys when I press Super. 
Should I file this a seperate bug?

If you believe this is an X bug please comment on the Debian bug! :)

Created attachment 31407 [details]
Log where the popup doesn't hide on Super release

Created attachment 31408 [details]
Log with the popup hiding after Super release (after xmodmap hack)

No, I think it's probably a Metacity bug, which only surfaced due to a change in
X.  Unfortunately, I don't understand all the details of what I've read on it,
and haven't had the time to check further.  See also the following bug reports
about this issue:

bug 142947
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122752
http://freedesktop.org/bugzilla/show_bug.cgi?id=926

Denis Barbier in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=259740 did
some useful debugging too:


I ran
  $ METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 \
       METACITY_DEBUG_BUTTON_GRABS=1 metacity
then launched
  $ gnome-keybinding-properties
and changed switching between windows by trying to map this action
to Super_L+Tab (as I tried several times, it may not have the
default value).
The log file contains (my comments are prefixed by a dash sign)
  Window manager: Metacity version 2.8.1 running on 09.09.2004 
  ...
  KEYBINDINGS: Binding "switch_windows" has new gconf value "Super_L"
  KEYBINDINGS: New keybinding for "switch_windows" is keysym = 0xffeb mods = 0x0
#   xev tells that Super_L is indeed 0xffeb, but modifiers are 0x40.
#   this output means that the Super_L key is pressed without modifiers,
#   so in fact it is not seen as a modifier, see <Alt>Tab below for
#   another example.
  ...
  SM: Initializing session with save file '(none)'
  SM: Obtained session ID 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
  Window manager: Opening display ':0.0'
  KEYBINDINGS: Display has keycode range 8 to 255
  KEYBINDINGS: Keysym Alt_L bound to modifier 0x8
  KEYBINDINGS: Keysym Meta_L bound to modifier 0x8
  KEYBINDINGS: Keysym Alt_L bound to modifier 0x8
  KEYBINDINGS: Keysym Meta_L bound to modifier 0x8
  KEYBINDINGS: Keysym Num_Lock bound to modifier 0x10
  KEYBINDINGS: Keysym Pointer_EnableKeys bound to modifier 0x10
  KEYBINDINGS: Keysym Super_L bound to modifier 0x40
#   as said above, so this binding is correct here
  KEYBINDINGS: Keysym Hyper_L bound to modifier 0x40
  KEYBINDINGS: Keysym Mode_switch bound to modifier 0x80
  KEYBINDINGS: Keysym ISO_Level3_Shift bound to modifier 0x80
  KEYBINDINGS: Ignoring modmask 0x12 num lock 0x10 scroll lock 0x0 hyper 0x40
super 0x40 meta 0x8
#   hey, is this message normal? are these modifiers all ignored?
  KEYBINDINGS: Rebuilding window binding table from preferences
  KEYBINDINGS:  11 bindings in table
  KEYBINDINGS: Rebuilding screen binding table from preferences
  KEYBINDINGS: Binding switch_windows also needs Shift grabbed
  KEYBINDINGS: Binding switch_panels also needs Shift grabbed
  KEYBINDINGS: Binding cycle_windows also needs Shift grabbed
  KEYBINDINGS: Binding cycle_panels also needs Shift grabbed
  KEYBINDINGS: Binding cycle_panels_backward also needs Shift grabbed
  KEYBINDINGS:  19 bindings in table
  KEYBINDINGS: Reloading keycodes for binding tables
  KEYBINDINGS:  Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_left)
  KEYBINDINGS:  Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_right)
  KEYBINDINGS:  Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_up)
  KEYBINDINGS:  Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_down)
  KEYBINDINGS:  Devirtualized mods 0x0 -> 0x0 (switch_windows)
  KEYBINDINGS:  Devirtualized mods 0x20 -> 0x1 (switch_windows)
  ...
  KEYBINDINGS: Binding "switch_windows" has new gconf value "Super_L"
  KEYBINDINGS: New keybinding for "switch_windows" is keysym = 0xffeb mods = 0x0
#   err, maybe mods is null because this modifier was ignored?
  ...
#   now let's define it to <Alt>Tab
  KEYBINDINGS: Binding "switch_windows" has new gconf value "<Alt>Tab"
  KEYBINDINGS: New keybinding for "switch_windows" is keysym = 0xff09 mods = 0x80
#   okay, 0xff09 is <Tab> (see keysymdef.h), and see below why mods
#   is 0x80 and not 0x8
  ...
  KEYBINDINGS: Rebuilding screen binding table from preferences
  KEYBINDINGS: Binding switch_windows also needs Shift grabbed
  ...
  KEYBINDINGS: Reloading keycodes for binding tables
  KEYBINDINGS:  Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_left)
  KEYBINDINGS:  Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_right)
  KEYBINDINGS:  Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_up)
  KEYBINDINGS:  Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_down)
  KEYBINDINGS:  Devirtualized mods 0x80 -> 0x8 (switch_windows)
  KEYBINDINGS:  Devirtualized mods 0xa0 -> 0x9 (switch_windows)
#   so here is how <Alt>Tab works.

To me, it looks like the line
  KEYBINDINGS: Ignoring modmask 0x12 num lock 0x10 scroll lock 0x0 hyper 0x40
super 0x40 meta 0x8 
is the root of this problem, ie. why Super keys do not work.

This bug was introduced by changes in xlibs, and upstream asserted that
he won't revert these changes because they are necessary for other
purposes, so we should try to help GNOME developers to see how this bug
can be fixed.  I see 2 ways: either find why Super keys are ignored,
or hack GNOME keyboard selector to map modifiers to different values.
The former is the best solution, but I am unable to help here.
Are there GNOME developers who are willing to debug this issue?

Bug 152169 is almost certainly a duplicate as well.  I think this bug is going
to affect just about everyone (Fedora, Debian, Gentoo, etc.) and we're going to
have a lot of unhappy users, so I'm marking priority as Urgent.

I'm willing to look at it, but I doubt if I can find the fix in anywhere close
to a reasonable amount of time.

Havoc, Rob?  Do either of you have time to look at this?  If not, do you have
any hints about where to look and what needs to be done?

I think you may be misinterpreting the admittedly confusing message about
ignored modifiers, see source:

  display->ignored_modifier_mask = (display->num_lock_mask |
                                    display->scroll_lock_mask |
                                    LockMask);

  meta_topic (META_DEBUG_KEYBINDINGS,
              "Ignoring modmask 0x%x num lock 0x%x scroll lock 0x%x hyper 0x%x
super 0x%x meta 0x%x\n",
              display->ignored_modifier_mask,
              display->num_lock_mask,
              display->scroll_lock_mask,
              display->hyper_mask,
              display->super_mask,
              display->meta_mask);

In other words the message is that 0x12 is ignored, and that super_mask is 0x40,
not that numlock/scrolllock/hyper/super/meta are all ignored.

I'm guessing the real problem is:
  KEYBINDINGS: Binding "switch_windows" has new gconf value "Super_L"
  KEYBINDINGS: New keybinding for "switch_windows" is keysym = 0xffeb mods = 0x0

The gconf value should be "<Super>Tab" not "Super_L" - "Super_L" means "press
only the super key, with no modifiers" - the message about "keysym = 0xffeb mods
= 0x0" means that the gconf value was parsed to be the keysym Super_L and
modmask 0, since there are no mods in the gconf setting.

Try setting the gconf setting to "<Super>Tab" instead. Or also "<Mod4>Tab"
probably works.

The real bug here may be in the keybindings control panel, if you used that to
set the gconf key.

Havoc: If I run the following in a terminal:

gconftool-2 --set /apps/metacity/global_keybindings/switch_windows --type string
"<Mod4>Tab"

Then Super-Tab will work perfectly fine to switch windows under Fedora 1 (uses
XFree86 3.3).  Under Fedora 2, however, I observe the same behavior as Ross. 
It's broken.  This was also reported in comments 10 and 16 of
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122752.

And it's not just Super that's broken.  Alt_R is too, and other modifier keys
may be as well.  In http://freedesktop.org/bugzilla/show_bug.cgi?id=926, the X
maintainer says that the old way modifier keys were handled was broken in his
opinion and that it caused problems with multi-layout keyboard setups.  So, he
removed approximately half the modifiers (the ones that tended to be used for
different things in different layouts?) from the xmodmap listing.  This seems to
affect all distros using a newer version of X, and Ivan says that he won't
revert the X changes that caused this.  He provides an alternate solution of
somehow using XKB, which I don't yet understand, since I know nothing about XKB.

Ooops, I meant s/XFree86 3.3/XFree86 4.3/.  Fedora 1 isn't *that* old.

OK, I don't deny it's broken, I was just commenting on that one particular line
of theorizing. We should maybe get a log with the gconf key set to the right
thing though from the fd.org bug it sounds like the problem is already
well-understood.

Reading the X bug I don't have any clever ideas really, other than revert the
xkb changes until we figure out a safer way forward...

Okay, makes sense.  See comments 7 and 8 for such a log which Ross provided. 
See also the attachment I posted to bug 142947 (which is a duplicate of this bug
or vice-versa) for a self-made log showing just the relevant debugging info.

Do you have rights to revert Xorg changes?

[Also, since the freedesktop.org bug is pretty hard to read and hard to find
info in, I'm just going to post the solution Ivan suggested here so that I can
refer to it more easily: 

"XKB could help them in this task.  Using XKB you can order a notification about
any modifier state changes.  Therefore if such WM used XKB features it could
just request special notification "Mod1 state is changed" and wait this event
instead of unreliable guessing what physical key controls this modifier."]

Right, using Xkb we could certainly have an alternate code path that got this
right. However, the old xkeymap codepath would never get tested again, pretty
much, and metacity would probably end up in practice requiring xkb... that's why
I was trying to just use the old X stuff.

I can't revert X.org changes, even if I could, Ivan maintains this stuff afaik.

Created attachment 32617 [details] [review]
A patch

This patch creates an alternate code path using XkbGetState to figure out if
the modifiers are still in place.

Not particularly nice, but I don't really see a better solution if we can't get
the X.org change reverted.

Awesome, thanks Soeren!  Rob, Havoc: here's a WORKSFORME vote.  I tried it out
on both my desktop and my laptop, testing both Ctrl-Alt-Arrow, Alt-Tab (right
alt in both cases, obviously) and Super-Tab (as a replacement for Alt-Tab--but
only on my laptop since my desktop doesn't have no stinkin' windows keys)  :-)

You mean with the patch right?

Yes, sorry for being unclear.  Without the patch none of those things work.

This looks good to me. The fact that the GetState is a round trip sort of sucks
(and creates a minor race condition), but should not matter in this case.

Since it's okay with Havoc, I'm applying to the gnome-2-8 branch and HEAD.  Kick
me if I wasn't supposed too do that...

committed.

*** Bug 159270 has been marked as a duplicate of this bug. ***

*** Bug 163524 has been marked as a duplicate of this bug. ***