Cannot use Windows key in keyboard shortcuts

Since Sunday is the day for incredibly difficult X bugs, judging by today's bug
flow, I'll take this one.

Under xev, what gets generated, a) when you press just your Windows key, b) when
you press Windows+somethingelse? With and without altwin:super_win would be
good. Although your options string looks weird. Does it work if you do
"setxkbmap -option 'altwin:super_win'", or possibly "setxkbmap -option
'altwin:superwin'"?

> Under xev, what gets generated, a) when you press just your Windows key,

KeyPress event, serial 26, synthetic NO, window 0x3600001,
    root 0x40, subw 0x0, time 3693983, (409,186), root:(414,257),
    state 0x0, keycode 115 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x3600001,
    root 0x40, subw 0x0, time 3694073, (409,186), root:(414,257),
    state 0x0, keycode 115 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:

> b) when you press Windows+somethingelse?

KeyPress event, serial 29, synthetic NO, window 0x3600001,
    root 0x40, subw 0x0, time 3715823, (409,186), root:(414,257),
    state 0x0, keycode 115 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 29, synthetic NO, window 0x3600001,
    root 0x40, subw 0x0, time 3716018, (409,186), root:(414,257),
    state 0x0, keycode 41 (keysym 0x66, f), same_screen YES,
    XLookupString gives 1 bytes: (66) "f"
    XmbLookupString gives 1 bytes: (66) "f"
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x3600001,
    root 0x40, subw 0x0, time 3716060, (409,186), root:(414,257),
    state 0x0, keycode 41 (keysym 0x66, f), same_screen YES,
    XLookupString gives 1 bytes: (66) "f"

KeyRelease event, serial 29, synthetic NO, window 0x3600001,
    root 0x40, subw 0x0, time 3716165, (409,186), root:(414,257),
    state 0x0, keycode 115 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:

> With and without altwin:super_win would be
> good. Although your options string looks weird. Does it work if you do
> "setxkbmap -option 'altwin:super_win'", or possibly "setxkbmap -option
> 'altwin:superwin'"?

andrew@trogdor ~ $ setxkbmap -option 'altwin:super_win'
Illegal map name '(inet(hpi6))+' in symbols name
'pc/pc(pc104)+pc/us(inet(hpi6))+altwin(super_win)'
andrew@trogdor ~ $ setxkbmap -option 'altwin:superwin'
Illegal map name '(inet(hpi6))' in symbols name 'pc/pc(pc104)+pc/us(inet(hpi6))'

Given these various errors, I'm not sure that I've successfully turned
altwin:super_win on :)

I think the GNOME keyboard manager is massively broken (Seb, ideas?). Could you
please try whether any of the following fix it?
setxkbmap -symbols 'inet(hpi6)' -option 'altwin:super_win'
setxkbmap -symbols 'us(inet(hpi6))' -option 'altwin:super_win'
setxkbmap -symbols 'pc(pc104)+us(inet(hpi6))' -option 'altwin:super_win'
setxkbmap -symbols 'pc(pc104)+us(inet(hpi6))+altwin(super_win)' -option ''

Seb, you win, dude. Setting symbols='us(pc104)+inet(hpi6)'
options='altwin:super_win' (which was my first guess as soon as Andrew called me
because I'd broken his XKB entirely, and I'm pretty sure is the right thing to
be doing) works fine, so reassigning to the GNOME keyboard thingy. Ez GTK boog. :)

what happen when you press the window key in the keybinding UI ?

(In reply to comment #5)
> what happen when you press the window key in the keybinding UI ?

It gives me e.g. <Mod4>1 with Daniel's workaround, and 0x73 (iirc) without.

so it doesn't act as a modifier and get it as a keybinding ?

(In reply to comment #7)
> so it doesn't act as a modifier and get it as a keybinding ?

Correct.

An upstream bug about this:
http://bugzilla.gnome.org/show_bug.cgi?id=165343

1. The bug in gnome and this one - are not relevant really
2. This is very odd configuration, actually. How did it happen that you got
layout 'us' with variant(!!!) 'inet(hpi6)'. Are you sure there is such a thing?

Actually, gnome-settings-daemon (2.9.x), executes:

setxkbmap -model 'pc104' -layout 'us(inet(hpi6))' -options 'altwin:super_win'

Does this command work? If not - there is a problem with your XKB configuration
repository. I would be interested to see your xkb/rules/xfree86.xml and
xkb/symbols/pc/us if possible.

(In reply to comment #10)
> 1. The bug in gnome and this one - are not relevant really
> 2. This is very odd configuration, actually. How did it happen that you got
> layout 'us' with variant(!!!) 'inet(hpi6)'. Are you sure there is such a thing?

My laptop is an HP NC6000. I believe hpi6 is the right setting for this
keyboard, or at least close enough to make my volume buttons work ;)

> Actually, gnome-settings-daemon (2.9.x), executes:
>
> setxkbmap -model 'pc104' -layout 'us(inet(hpi6))' -options 'altwin:super_win'
>
> Does this command work? If not - there is a problem with your XKB configuration
> repository. I would be interested to see your xkb/rules/xfree86.xml and
> xkb/symbols/pc/us if possible.

No, it doesn't work:

andrew@trogdor ~ $ setxkbmap -model 'pc104' -layout 'us(inet(hpi6))' -options
'altwin:super_win'
Error! Option "-options" not recognized

I'll attach the files you're asking for.

Created an attachment (id=1448)
xkb/rules/xfree86.xml

Created an attachment (id=1449)
xkb/symbols/pc/us

Andrew: Well, what you probably should do is: in gnome-keyboard-properties,
choose your MODEL: "Hewlett Packard Internet Keyboard", then LAYOUT "USA",
OPTION "Super is mapped to the Win-keys (default)". I do not understand how you
managed to choose the HP (hpi6) as VARIANT - it is simply _incorrect_.
Sorry, the right command line is:
setxkbmap -model 'pc104' -layout 'us(inet(hpi6))' -option 'altwin:super_win'
(not 'options' but 'option') - and it should fail. But this one should work:
setxkbmap -model 'hpi6' -layout 'us' -option 'altwin:super_win'

Sorry, try this:
setxkbmap -model pc104 -layout 'us(inet(hpi6))' -option 'altwin:super_win'

(note s/options/option/)

(In reply to comment #15)
> Sorry, try this:
> setxkbmap -model pc104 -layout 'us(inet(hpi6))' -option 'altwin:super_win'
>
> (note s/options/option/)

No luck:

andrew@trogdor ~ $ setxkbmap -model pc104 -layout 'us(inet(hpi6))' -option
'altwin:super_win'
Illegal map name '(inet(hpi6))+' in symbols name
'pc/pc(pc104)+pc/us(inet(hpi6))+altwin(super_win)'

(In reply to comment #14)
> Andrew: Well, what you probably should do is: in gnome-keyboard-properties,
> choose your MODEL: "Hewlett Packard Internet Keyboard", then LAYOUT "USA",
> OPTION "Super is mapped to the Win-keys (default)". I do not understand how you
> managed to choose the HP (hpi6) as VARIANT - it is simply _incorrect_.
> Sorry, the right command line is:
> setxkbmap -model 'pc104' -layout 'us(inet(hpi6))' -option 'altwin:super_win'
> (not 'options' but 'option') - and it should fail. But this one should work:
> setxkbmap -model 'hpi6' -layout 'us' -option 'altwin:super_win'

You're right, that second setxkbmap line works just fine.

Also, configuring gnome-keyboard-properties as you describe seems to work,
although I get the "Error activating XKB configuration." dialog. I suspect that
may be due to misconfiguration in my xorg.conf file, though (where hpi6 is set
as the variant)?

It's too long ago for me to remember, but I think I probably set hpi6 as the
variant based on searching google for how to make the keys on this laptop work,
but I honestly don't remember, and can't find any such page on google now.

Thanks for your help!

Ghm. I'm happy you got your configuration working. But I am unhappy with the
error dialog. Which version of gnome-control-center/libxklavier do you use?
Could you play around your configuration (for example, remove the option and add
it again - or change keyboard to something like "generic pc 105") - and find out
which configuration element, when used, causes the trouble?

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

Same problem here. My specs:

- fresh Hoary install (no earlier Ubuntu experience)
- keyboard model is Generic 105 (intl) PC
- Finnish key layout
- Keyboard Shortcuts gives either Super_L or Super_R when attempting to bind
- Super mapped to Win-keys

is that still an issue for somebody?

(In reply to comment #21)
> is that still an issue for somebody?

Works ok for me on Breezy, once I set "Super is mapped to the Win-keys" in my
System -> Preferences -> Keyboard -> Layout Options -> Alt/Win key behaviour.

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

It Works with Andrew's trick. But this should be the default beaviour.

Is this bug still relevant or was it fixed ?

I am using Dapper and I have this problem. Perhaps it is related to Bug #19493?

The Alt/Win key behaviour on the Keyboard Preferences has 2 defaults. I'm assuming this is a typo, but has no effect on the selection. Regardless, none of these options allows my windows key(s) to be used as a modifier in keyboard shortcuts.

I have a logitech iTouch keyboard.

I had a similar problem; I could assign Super as shortcut, but not use it as a modifier for a shortcut.

 dkr@eos:~% xmodmap -pm |grep Super
mod4 Super_L (0x7f), Hyper_L (0x80)

 I "set "Super is mapped to the Win-keys" in my
System -> Preferences -> Keyboard -> Layout Options -> Alt/Win key behaviour." as per above advice.

 dkr@eos:~% xmodmap -pm |grep Super
mod4 Super_L (0x73), Super_R (0x74), Super_L (0x7f), Hyper_L (0x80)

Now I can use windows key as a modifier key in keyboard-shortcuts(shows up as <Mod4>)

I forgot to mention that this was with Breezy upgraded to Dapper.

I have the same sort of problem with breezy and dapper. I mapped the windows key to super, and i can use winkey+t to start a terminal and i can use winkey+1...4 to switch to desktop 1...4.

I can also set winkey+e to home folder, and winkey+l to lock screen.. but when I press the keys, nothing happens.

Thanks Danny. After changing from the default in Alt/Win keys to a different setting also marked default - not to be confused with the third setting marked default) I can now set <mod4>+l to lock my screen.

Like Demon, this doesn't actually work. Thankfully the upstream bug explains it.

There are two bugs here:
- A default that is different to what we expected in the keyboard defaults; and
- Gnome not carrying out some functions set using the Windows key.

It would be great if this issue could get fixed without remapping the key in xmodmap. It works great as is in KDE and remapping the key will break the setup of Kubuntu users.

I got <Mod4>+L to lock my screen working in a rather filthy way.
I changed command_1 in /apps/metacity/keybinding_commands to gnome-screensaver-command --lock
And I also changed run_command_1 in /apps/metacity/global_keybindings to <Mod4>L

This seems to be working...

Bert's work-around works for me as well.
Any progress on fixing this, though? (Enabling users to set this in System->Preferences->Keyboard Shortcuts?)

I'm having this problem in the latest Feisty beta, and even the gconf-editor work-around seems to not function anymore. I'm using xbindkeys as a fallback but the problem seems to be getting worse...

This is still not working in Feisty. This thread seems a bit complex, bug #16815 seems to more closely match my problem. The key is recognized as a modifier (Mod4), but it only works for some commands. For instance, it works for starting a new terminal, but it doesn't work for locking the screen.

same problem on feisty final, amd64. if i try to assign a key combination - let's say win-key+x - to "execute" i hit the win-key and then the dialog ends, and "super l" is stored. when i hit the windows key, keep it pressed, then click on the desired action, then hit x, the combination "Mod4+x" is stored and everything works.

SUPER (WIN) modification -key can be binded in gconf: /apps/gnome_settings_daemon/keybindings. I successfully set volume control to <WIN>KP_Down, <WIN>KP_Up in Feisty.

For what it's worth, IceWM in Feisty supports the use of the Windows key as a modifier (in a key combination) and as a stand-alone shortcut simultaneously, i.e., the correct behavior.

This should be supported in Gnome via Preferences->Keyboard Shorcuts.

I have done a completely fresh install of Feisty on my laptop. (Compaq Presario 2100)
In keyboard preferences I set the keyboard model to "Laptop/notebook Compaq (eg. Presario) Internet Keyboard"
On the layout options tab I set the "Alt/Win key behavior" to "Super is mapped to the win-keys (default)"

If I go into Keyboard Shortcuts I can assign shortcuts based on the windows key.
For example Win+L to lock the screen and Win+T to open a terminal window.
They assign as Mod4+L and Mod4+T respectively.

If I hit Win+L, the screen doesn't lock. Nothing happens.
If I hit Win+T, I get a new terminal window.

Could a lot of people in this thread be talking about a similar issue. Trying to get Win+L to lock their screen?
What would cause the keyboard shortcuts to work for everything else, but not locking the screen?

Fixed in Intrepid

Not fixed in intrepid!

In intrepid we need to go:

System -> Preferences -> Keyboard -> Setup

"Meta is mapped to the win keys" to make the windows key work as a modifier!

Yes, as I previously commented[1], the keyboard layouts need to be changed to incorporate that setting by default!!

[1] https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/12153/comments/60

I also confirm that is not fixed in Intrepid final. Reopen?

This is still a problem in Intrepid. It registers "Super L", but not "Super L + something". I previously would work around this by holding down Super, then clicking "New shortcut" and then pressing the letter, but this doesn't work anymore.

In intrepid we need to go:

System -> Preferences -> Keyboard -> Setup

"Meta is mapped to the win keys" to make the windows key work as a modifier!

but now I've got another problem: When this option above is not choosen (and Super is not mapped to the Mod4) the Super_L key has no affect when trying to use any shortcut (for exemple I want to set Strg+SuperL to open my Homefolder, but when i use this combination nothing happens)
I'm useing Intrepid (in Hardy it worked fine for me.

Alex

> In intrepid we need to go:
>
> System -> Preferences -> Keyboard -> Setup

It's System -> Preferences -> Keyboard -> Layouts tab -> Other Options... button

> "Meta is mapped to the win keys" to make the windows key work as a modifier!

That's not really a solution; just a workaround. the Windows key maps to Super by default, so we should be able to use Super in keyboard shortcuts.

This is the point, you're right, it is mapped to Super by default but when I try to use Super in a shortcut it has no affect. (declaring a shortcut with Super works and in Hardy Heron even using Super worked...)

Alex

Same issue in Jaunty alpha5.
 Super not acting as starting main menu eventhough in the keyboard short cut settings it is mapped correctly.

somebody having the issue should open the bug on GNOME

Yes -- broken on Hardy, Intrepid and Jaunty. Changing "Super is mapped to Win keys" fixes it.

Is this really an issue for GNOME now, rather than a default configuration issue with Ubuntu?

I don't see how bug #1 will ever get fixed with this one open. It's nothing to do with unusual keyboards: it's something trivial, used by many computer users, which is broken out of the box.

The GNOME bugzilla bug is unhelpfully marked as FIXED RESOLVED. I will reopen it.

Original upstream http://bugzilla.gnome.org/show_bug.cgi?id=165343 is still marked as fixed; some disagreement as to what that bug was about.

I have opened a new upstream bug in libgnomekbd over the default layouts, as per Nelson's comment above. http://bugzilla.gnome.org/show_bug.cgi?id=579658

I think this would fix the problem:
System > Preferences > Keyboard > Layouts > Layout Options > Alt/Win key behavior > Meta is mapped to Win keys

That's a workaround, not a fix, and has been mentioned in this and the upstream tickets.

It's fixed when it's not broken out of the box.

i have the same problem in Jaunty (after the upgrade from intepid).

a have a question about this issue:
Does smkururu's suggestion resolve the problem or it will appear at each reboot?
does his suggestion provoke any side-effect?

yesterday i tried the workaround proposed by smkururu and i answered some questions written by me (see https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/12153/comments/106):
changing 'System > Preferences > Keyboard > Layouts > Layout Options > Alt/Win key behavior' to 'Meta is mapped to Win keys' the effect is that the AltGr button does not have a behaviour like before: no key-combination is available (i cannot use the character '@' with AltGr + ò, for example).

i think this is a bad side-effect.

any news about this issue?

Yesterday, I tried the workaround proposed by smkururu.
The side effect is that in Emacs Meta key is know <Win> key, and <Alt> is no more usable in Emacs.
This is not an acceptable workaround.

any news?

Thank you for bringing this bug to our attention. Unfortunately a paper cut should be a small usability issue that affects many people and is quick and easy to fix. I'm afraid this bug can't be addressed as part of this project.
A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10.

I've just read through this entire thread - to summarize:

It seems we have two/three issues:

1) The out-of-the-box behaviour only allows the windows key to be used on it's own, not as part of a shortcut using the keyboard shortcut applet

2) The workaround of setting super or meta is mapped to the windows key only makes it work for some commands but not others - someone suggested this is due to whether the shortcuts are stored in different places:
  Philipp Kohlbecher wrote on 2007-06-04:
  The difference seems to be that the shortcut for launching the terminal is set in gconf setting /apps/metacity/global_keybindings (as is the shortcut for minimizing all windows to show the desktop, for example), while the shortcut for locking the screen is set in /apps/gnome_settings_daemon/keybindings (as is the shortcut for launching the web browser, for example)

3) The workaround apparently breaks the behaviour of Alt Gr:
   alca wrote on 2009-04-27:
  yesterday i tried the workaround proposed by smkururu and i answered some questions written by me (see https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/12153/comments/106):
changing 'System > Preferences > Keyboard > Layouts > Layout Options > Alt/Win key behavior' to 'Meta is mapped to Win keys' the effect is that the AltGr button does not have a behaviour like before: no key-combination is available (i cannot use the character '@' with AltGr + ò, for example)

Anyone have anything to add? More details, more complaints, progress updates? Do we have any developers looking into this?

On Mon, 2009-06-22 at 15:56 +0000, Sam Illingworth wrote:h
> The difference seems to be that the shortcut for launching the
> terminal is set in gconf setting /apps/metacity/global_keybindings (as
> is the shortcut for minimizing all windows to show the desktop, for
> example), while the shortcut for locking the screen is set
> in /apps/gnome_settings_daemon/keybindings (as is the shortcut for
> launching the web browser, for example)

Which begs the question... Why isn't there a central place for all
keybindings and mouse + stylus gestures? That would be the best thing,
so that there's less of a question as to what application controls
bindings where, perhaps... ?

--
Karl Hegbloom <email address hidden>

Great comment, Sam. This is getting complicated. Can I propose a simple solution?

In comment 103 of this I described the original upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=165343

The maintainer insist it's fixed but I disagreed, so I opened another against libgnomekbd as per his suggestion: http://bugzilla.gnome.org/show_bug.cgi?id=579658

Neither one seems to have gone anywhere.

PROBLEM: We can't bind-meta key combinations out of the box without changing configuration and getting unpleasant side-effects.

OBSERVATION: Compiz' CCSM tool captures the right keys perfectly out of the box.

SOLUTION: Delete the code in GNOME keyboard settings and replace it with CCSM code.

Perhaps I'm overlooking some huge technical complexity here, and maybe God kills a kitten every time the CCSM code is run, but really... it better be a big kitten for us not to use it. I'm sure the right fix involves patching libgnomekbd and blah blah blah but life is too short. And 4 years of open bug is too long.

how can a "medium" severity bug be OPEN for 4 years... 4 years is long...

could somebody having the issue on jaunty take that to GNOME?

Aidan Fitzpatrick suggested the issue depends on gnome keyboard settings...

Moreover, I do appreciate irony, but kidding apart, how can a bug like this be 'low' priority?
According to 'medium' priority definition in launchpad:
   "The bug is an inconvenience for MANY users. The feature provides new ways of completing tasks.[...]"

Furthermore, IMHO a bug preventing any Ubuntu users from using a particular keyboard well known button simply can't be considered 'low'.

Well, with Super mapped to the win keys I can now (in Jaunty) use the Windows key in any short-cut, so that appears to be part of this bug fixed. If other Jaunty users can confirm this is fixed then all that remains is to change the default setting when Ubuntu is installed.

Would that be a design decision though? If you change it to Super so you can use it as a modifier you lose the ability to use the Windows key on its own (anyone know of a workaround for that?). What's the procedure for proposing a change like this, and does everyone agree this is now working in Jaunty?

Fixed for me in Jaunty.
I can lock my screen by setting the shortcut MOD4+L.
It also works correctly when connected to a Windows machine via rdesktop.

The second upstream bug I created has run its course: http://bugzilla.gnome.org/show_bug.cgi?id=579658

Suggestion is that the symbols/pc file is out of date. I will test this on my Jaunty. Others, how does it work for you?

Remember NOT to use "Super is mapped to Win keys" when testing this. That is a workaround... which we already know works, but which causes other problems. I'm trying to get Windows shortcut keys working out of the box.

upstream suggests it's an issue in xkeyboard-config

Sebastien

Upstream suggested it's an issue in xkeyboard-config _if_ the /usr/share/X11/xkb/symbols/pc file provided didn't work.

I have just tested the file that Sergey attached to the upstream and it works perfectly.

I think it's reasonable to assume the problem is our xkeyboard-config symbols/pc files are out of date.

Frustratingly, both the default file on Jaunty and the "newer", working file that Sergey sent have the same timestamp: "// $XFree86: xc/programs/xkbcomp/symbols/pc,v 1.9 2003/06/09 19:59:46 dawes Exp $"

How can we get the distro symbols/pc file updated?

Sorry for the comment spam. Last one. The difference between the working and broken pc files is this:

x@y:~$ diff pc.broken-jaunty pc.fixed-sergey
22,25c22
< key <BKSP> {
< type="CTRL+ALT",
< symbols[Group1]= [ BackSpace, Terminate_Server ]
< };
---
> key <BKSP> { [ BackSpace ] };
37a35
> modifier_map Mod4 { <LWIN> };
42a41
> modifier_map Mod4 { <RWIN> };

the karmic version seems identic to the fixed one you added there, could you try on karmic?

Sebastien

I've just installed Karmic Alpha 5 under VirtualBox 3.0.4: it is even more broken.

It recognises left Windows key + R as "Alt + R" ("Alt + R" comes up as "Alt + R", too).

It recognises right Windows key as "ISO Level 3 Shift" and won't accept a modifier.

The XKB xprop settings are the same as on Jaunty.

Maybe this is an artefact of VirtualBox's key mapping, rather than a new problem? I hope so.

hi i have de same problem that aidan, i am using karmic koala beta

The problem is definitely solved for me in a clean Karmic 32 and 64 bits installation.

Please confirm.

Works for me in fresh Karmic install :)

I'm using the Karmix Live CD on a Lenovo T61 and it doesn't work for me. I am unable to bind <Super><Shift>1 (for example), either by typing it into Metacity or using the Keyboard Shortcuts application.

Upstream marked as RESOLVED NOTGNOME.