Metacity doesn't handle KeyRelease event for Super_L

Bug #18668 reported by Rui Matos
8
Affects Status Importance Assigned to Milestone
metacity (Ubuntu)
Fix Released
Medium
Sebastien Bacher

Bug Description

Using Breezy updated to this moment,
here is a description to get to the problem:

1. Go to Keyboard Preferences -> Layout Options -> Alt/Win key behaviour
2. Select "Super is mapped to the Win-keys (default)."
3. Go to Keyboard Shortcuts -> Window Management -> Move between windows with popup
4. Click on it to modify
5. Press Left Win key followed by Tab while still pressing the Win key. It
should read: <Mod4>Tab
6. Use Mod4+Tab as Alt+Tab

It doesn't work the same way as Alt+Tab yet it should. I'd like to free Alt for
other uses.

xev(1) reports for Alt:

KeyPress event, serial 29, synthetic NO, window 0x3200001,
    root 0x4c, subw 0x0, time 1172134, (270,674), root:(1130,758),
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x3200001,
    root 0x4c, subw 0x0, time 1173005, (270,674), root:(1130,758),
    state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:

and for the Left Win key:

KeyPress event, serial 29, synthetic NO, window 0x3200001,
    root 0x4c, subw 0x0, time 1235469, (103,133), root:(963,217),
    state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x3200001,
    root 0x4c, subw 0x0, time 1238372, (103,133), root:(963,217),
    state 0x40, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:

thus X seems to get the KeyRelease event nicely for both keys while metacity
doesn't.

Revision history for this message
Sebastien Bacher (seb128) wrote :

thanks for your bug. is that a new issue due to some xorg update?

Revision history for this message
Rui Matos (tiagomatos) wrote :

(In reply to comment #1)
> thanks for your bug. is that a new issue due to some xorg update?

I haven't tried before. Is it not reproducible?

Revision history for this message
Sebastien Bacher (seb128) wrote :

I get this behaviour too. That seems to be the same bug as
http://bugzilla.gnome.org/show_bug.cgi?id=151554 which is supposed to be fixed.
That could be due to an xorg change ...

Revision history for this message
Rui Matos (tiagomatos) wrote :

I'm not sure if it directly related but I'm having the problem described in

https://bugzilla.ubuntu.com/show_bug.cgi?id=12184

which seems to be caused by changes in xorg since that problem didn't exist in
hoary for example. Which leads me to think that maybe this one was also caused
by some xorg change.

Revision history for this message
Rui Matos (tiagomatos) wrote :

Just found this:
http://necrotic.deadbeast.net/svn/xfree86/trunk/debian/local/FAQ.xhtml#xkbnewlayout

Using setxkbmap -option "altwin:super_win" steps 1 and 2 from my description
above are no longer needed but the rest is exactly the same.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Fresh breezy install, this is still happening. The GNOME Keyboard Shortcuts
dialog seems to have the same problem, if you try and assign a shortcut of
(e.g.) Super+R to a key, it stops at Super_L and just assigns that.

It's as though GTK+ thinks the Super_L key is an ordinary key, and not going to
behave as a modifier.

I've had a long-running XKB hack to get around this, but it's just that, a hack.

Revision history for this message
Daniel Stone (daniels) wrote :

Maybe XKB support went wandering again? Super_L would be handled as a
non-modifier single key if it was just using core keyboard support -- and Mod4
is a sign of falling back to core keyboard events and not using XKB.

Revision history for this message
Rui Matos (tiagomatos) wrote :

I've been upgrading daily through breezy and as of today this seems fixed.
Unfortunately I hadn't tried it for a while so I don't know which upgrade fixed it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.