Ubuntu

Cannot use Windows key in keyboard shortcuts

Reported by Andrew Bennetts on 2005-01-23
270
This bug affects 17 people
Affects Status Importance Assigned to Milestone
gnome-control-center
Unknown
Medium
xkeyboard-config (Ubuntu)
Low
Binh Long Pham
Declined for Hardy by Steve Langasek
Declined for Jaunty by Sebastien Bacher

Bug Description

I've just upgraded to hoary, and now I'm seeing something that looks a lot like
bug #8146: my windows key is no longer able to be assigned to keyboard
shortcuts, and the existing shortcuts I had that use it don't work anymore.

I've tried to use the altwin:super_win workaround described in comments 16 and
18 of #1390, but I get "Error activating XKB configuration". The output of the
commands that error dialog suggests are:

andrew@trogdor ~ $ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "pc104", "us", "inet(hpi6)", ""
_XKB_RULES_NAMES(STRING) = "xfree86", "pc104", "us", "inet(hpi6)", ""
andrew@trogdor ~ $ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 layouts = [us inet(hpi6)]
 model = pc104
 overrideSettings = false
 options = [altwin altwin:super_win]

I'm not sure what package is responsible, so I'm leaving as UNKNOWN, but CCing
Daniel Stone because he probably knows :)

http://bugzilla.gnome.org/show_bug.cgi?id=165343: http://bugzilla.gnome.org/show_bug.cgi?id=165343

Daniel Stone (daniels) wrote :

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'"?

Andrew Bennetts (spiv) wrote :

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

Daniel Stone (daniels) wrote :

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 ''

Daniel Stone (daniels) wrote :

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

Sebastien Bacher (seb128) wrote :

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

Andrew Bennetts (spiv) wrote :

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

Sebastien Bacher (seb128) wrote :

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

Andrew Bennetts (spiv) wrote :

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

Correct.

Sebastien Bacher (seb128) wrote :
Sergey V. Udaltsov (svu) wrote :

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.

Andrew Bennetts (spiv) wrote :

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

Andrew Bennetts (spiv) wrote :

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

Andrew Bennetts (spiv) wrote :

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

Sergey V. Udaltsov (svu) wrote :

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'

Daniel Stone (daniels) wrote :

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

(note s/options/option/)

Andrew Bennetts (spiv) wrote :

(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)'

Andrew Bennetts (spiv) wrote :

(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!

Sergey V. Udaltsov (svu) wrote :

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

Jussi Pakkanen (jpakkane) wrote :

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

Sebastien Bacher (seb128) wrote :

is that still an issue for somebody?

Andrew Bennetts (spiv) wrote :

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

Sebastien Bacher (seb128) wrote :

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

Gorka Navarrete (emrys) wrote :

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

Lionel Dricot (ploum) wrote :

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.

lexual (lexhider) on 2006-04-25
Changed in control-center:
status: Unconfirmed → Confirmed

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.

Bert Hekman (bert-demontpx) wrote :

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.

Aaron Whitehouse (luna-tick) wrote :

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.

hunger (hunger) wrote :

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.

Changed in control-center:
status: Unconfirmed → Confirmed
Bert Hekman (bert-demontpx) wrote :

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

Philipp Kohlbecher (xt28) wrote :

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

Bogdan Butnaru (bogdanb) wrote :

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.

der_vegi (m-may) wrote :

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.

Cardy (andrei-bogomolov) wrote :

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.

emags (magius-eternal) wrote :

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.

Aaron C. de Bruyn (darkpixel) wrote :

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?

Changed in control-center:
status: Confirmed → Triaged
Changed in gnome-control-center:
status: Confirmed → Fix Released
Changed in control-center:
status: Triaged → Fix Committed
Changed in gnome-control-center:
status: Fix Committed → Fix Released
Changed in gnome-control-center:
status: Fix Released → Confirmed
Changed in gnome-control-center:
status: Fix Released → Confirmed
Changed in gnome-control-center:
status: Confirmed → Fix Released
Changed in gnome-control-center:
status: Confirmed → Fix Committed
51 comments hidden view all 131 comments
Andreas Moog (amoog) wrote :

Fixed in Intrepid

Changed in gnome-control-center:
assignee: seb128 → desktop-bugs
status: Fix Committed → Fix Released

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!

Nelson Benitez (gnel) wrote :

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

der_vegi (m-may) wrote :

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

der_vegi (m-may) on 2008-11-09
Changed in gnome-control-center:
status: Fix Released → Confirmed
Endolith (endolith) wrote :

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.

Alois (flugtiger) wrote :

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

Endolith (endolith) wrote :

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

Alois (flugtiger) wrote :

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

Joby Joseph (badjoby) wrote :

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

Sebastien Bacher (seb128) wrote :

somebody having the issue should open the bug on GNOME

Aidan Fitzpatrick (afit) wrote :

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.

Aidan Fitzpatrick (afit) wrote :

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

smkururu (smkururu) wrote :

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

Aidan Fitzpatrick (afit) wrote :

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.

alca (alcaweb) wrote :

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?

alca (alcaweb) wrote :

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.

gidantribal (aedo999) wrote :

any news?

Martin Albisetti (beuno) wrote :

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.

Changed in hundredpapercuts:
status: New → Invalid
Sam Illingworth (mazz0) wrote :

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>

Aidan Fitzpatrick (afit) wrote :

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.

gidantribal (aedo999) wrote :

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

Sebastien Bacher (seb128) wrote :

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

Changed in gnome-control-center (Ubuntu):
importance: Medium → Low
gidantribal (aedo999) wrote :

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

gidantribal (aedo999) wrote :

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

Sam Illingworth (mazz0) wrote :

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?

Aaron C. de Bruyn (darkpixel) wrote :

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.

Aidan Fitzpatrick (afit) wrote :

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.

Vish (vish) on 2009-09-05
affects: hundredpapercuts → null
Sebastien Bacher (seb128) wrote :

upstream suggests it's an issue in xkeyboard-config

Changed in gnome-control-center:
status: Fix Released → Unknown
affects: gnome-control-center (Ubuntu) → xkeyboard-config (Ubuntu)
affects: xkeyboard-config (Ubuntu) → gnome-control-center (Ubuntu)
affects: gnome-control-center (Ubuntu) → xkeyboard-config (Ubuntu)
Changed in xkeyboard-config (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
Aidan Fitzpatrick (afit) wrote :

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?

1 comments hidden view all 131 comments
Aidan Fitzpatrick (afit) wrote :

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> };

Sebastien Bacher (seb128) wrote :

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

Aidan Fitzpatrick (afit) wrote :

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.

ramses delgado (ramsesdm) wrote :

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

Gorka Navarrete (emrys) wrote :

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

Please confirm.

Gorka Navarrete (emrys) on 2009-11-06
Changed in xkeyboard-config (Ubuntu):
status: Confirmed → Fix Released
Changed in null:
status: Invalid → Fix Released
Sam Illingworth (mazz0) wrote :

Works for me in fresh Karmic install :)

Joe Casadonte (jcasadonte) wrote :

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.

Changed in gnome-control-center:
importance: Unknown → Medium

Upstream marked as RESOLVED NOTGNOME.

Curtis Hovey (sinzui) on 2011-11-11
no longer affects: null
Changed in xkeyboard-config (Ubuntu):
assignee: nobody → Binh Long Pham (long2511-mdd)
Displaying first 40 and last 40 comments. View all 131 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

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