After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 348172 - Super_L and Super_R keys are not modifier keys in Keyboard Shortcuts
Super_L and Super_R keys are not modifier keys in Keyboard Shortcuts
Status: RESOLVED DUPLICATE of bug 165343
Product: gnome-control-center
Classification: Core
Component: [obsolete] Keybinding
2.14.x
Other All
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-07-20 19:22 UTC by d_m
Modified: 2006-07-22 12:19 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description d_m 2006-07-20 19:22:54 UTC
Please describe the problem:
When choosing keyboard shortcuts, if I hit the "windows key" on my keyboard, plus another key (i.e. "1") then the binding shows up as just "Super_L". This is a different behavior than I get from the Alt or Control keys, which modify another keypress.

According to xev, my left windows key generates this:

KeyPress event, serial 29, synthetic NO, window 0x3200001,
    root 0x45, subw 0x0, time 2371992013, (171,0), root:(176,73),
    state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

Ideally, I could bind "super+1", "super+2" and so forth, to different actions.

Steps to reproduce:
1. Find a key on your keyboared that produces Super_L, or use xmodmap to create one
2. Open the Keyboard Shortcuts
3. Try to bind "Super_L + 1" to an action


Actual results:
The action is bound to just "Super_L" and if you try to bind another action to "Super_L + 2" then the first binding disappears.

Expected results:
I would expect to see something like <Super>1, which is similar to <Alt>1, which is what I get when I use Alt+1.

Does this happen every time?
Yes.

Other information:
Comment 1 Thomas Thurman 2006-07-21 13:06:26 UTC
Verified with control-center 2.15.4.
Comment 2 Thomas Thurman 2006-07-22 00:24:35 UTC
I am reasonably certain that this happens because of a curious infelicity in xmodmap. (I'll come over and verify this at your desk on Monday.)

When you say "Super", there are three things you might mean:

1) the keysyms Super_L and Super_R, which are just keysyms.
2) a key bound to one of these (in this case, your Windows key)
3) whichever one of the X modifiers GTK happens to think is "super" at the moment (let's suppose it's mod4).

GTK decides which X modifier is "super" by seeing which one is bound to a Super key.

Now in your case, you've used xmodmap's "keysym" command to map the Windows key to Super_L. But that doesn't automatically put the keysym into the modifiers table. In particular, you probably already had some other key (perhaps one you don't already have on your keyboard) bound to Super_L; therefore if you look at the current bindings using "xmodmap" with no arguments, you will still see Super_L listed against mod4 (or whichever it is), but it will have the keycode of the *other* Super_L.

In this case, when control-center asks X which keys are modifiers and gets a list back, the list doesn't contain the keystroke for your Windows key (because you haven't added it as a modifier). Thus, control-center is behaving correctly. GTK still believes that mod4 (or whatever) is Super, because the OTHER Super_L is still bound to it.

You need to use xmodmap's "add" and "remove" commands to put the Windows key into the modifiers table.
Comment 3 d_m 2006-07-22 02:19:42 UTC
Well, I will check this on Monday. I'm on my other keyboard now that doesn't have a windows key.

But... I definitely am not using xmodmap or anything else; this is the default set up that X.org gave me.
Comment 4 Olav Vitters 2006-07-22 12:19:13 UTC

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