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 133815 - keys refuse to "unbind"
keys refuse to "unbind"
Product: gnome-control-center
Classification: Core
Component: [obsolete] Keybinding
Other Linux
: High major
: 2.16
Assigned To: Control-Center Maintainers
Control-Center Maintainers
: 135476 143000 148969 154297 154940 154944 162904 164279 304999 311741 325865 332695 341992 351305 (view as bug list)
Depends on:
Reported: 2004-02-08 18:57 UTC by hrishiut
Modified: 2007-01-08 17:12 UTC
See Also:
GNOME target: 2.18.x
GNOME version: 2.15/2.16

patch for acme (6.85 KB, patch)
2004-03-17 11:31 UTC, Bastien Nocera
rejected Details | Review
restore the original keysym when unbinding a key (5.28 KB, patch)
2004-03-17 11:46 UTC, Bastien Nocera
rejected Details | Review
gcc-no-keysym-binding.patch (9.48 KB, patch)
2006-01-11 13:35 UTC, Bastien Nocera
committed Details | Review
what i built into rawhide (5.16 KB, patch)
2006-08-25 00:32 UTC, Ray Strode [halfline]
none Details | Review
add defaults in schema too for the standard keysyms (7.50 KB, patch)
2006-08-25 00:45 UTC, Ray Strode [halfline]
none Details | Review
Don't allow key combinations that probably aren't multimedia keys (5.66 KB, patch)
2006-11-15 05:18 UTC, Ray Strode [halfline]
none Details | Review
Don't allow key combindations that probably aren't multimedia keys and save keycode instead of keysym in gconf (6.10 KB, patch)
2006-11-15 16:58 UTC, Ray Strode [halfline]
none Details | Review
Use D-Bus interface for the multimedia player keys (12.96 KB, patch)
2007-01-02 00:53 UTC, Jan Arne Petersen
none Details | Review
Updated D-Bus interface for the media player keys. (13.59 KB, patch)
2007-01-04 00:59 UTC, Jan Arne Petersen
needs-work Details | Review
A sample plugin for banshee which uses the D-Bus interface defined above. (4.16 KB, text/x-csharp)
2007-01-04 01:02 UTC, Jan Arne Petersen
alternative implementation integrated into the org.gnome.SettingsDaemon interface (15.78 KB, patch)
2007-01-06 18:54 UTC, Jan Arne Petersen
committed Details | Review

Description hrishiut 2004-02-08 18:57:43 UTC
From: Debian User <>
X-Mailer: bug-buddy 2.4.2
Subject: keys refuse to "unbind"

Distribution: Debian testing/unstable
Description of Problem:
I set the "Pause" multimedia key as the "p" key on my keyboard.  I then
unset the Pause key (using Backspace). But later I was unable to type
"p" on my terminal (or any other text entry place). The only way I could
fix teh problem was by crashing X (ctrl-alt-backspace) and then
re-starting. If I had logged out I may have permanently lost the use of
the "p" key!!

Steps to reproduce the problem:
1.  Applications->Desktop->Multimedia Keys
2.  Click on "Pause Key" and hit "P"
3.  Click on "Pause Key" again and hit Backspace
4.  Try using the "P" key in an xterm

Actual Results:
"P" is not printed on the terminal

Expected Results:
The key should be rinted

How often does this happen?

Additional Information:
The only fix seems to be ctrl-alt-backsace
Comment 1 Jason D. Hildebrand 2004-02-12 18:23:05 UTC
I've reproduced this bug using the instructions provided.  

FWIW, I noticed that the keyboard layout switcher applet will restore
the keys if you switch to another keymap and then back again.
Comment 2 Bastien Nocera 2004-03-17 11:31:59 UTC
Created attachment 25728 [details] [review]
patch for acme
Comment 3 Bastien Nocera 2004-03-17 11:45:31 UTC
The same patch for the control-center below.
Jonathan and Jody will decide if it's worth adding for GNOME 2.4.
Comment 4 Bastien Nocera 2004-03-17 11:46:48 UTC
Created attachment 25729 [details] [review]
restore the original keysym when unbinding a key
Comment 5 Jody Goldberg 2004-04-07 16:15:20 UTC

spawning xmodmap to dump the keys then parsing the result ??  We can look that
sort of thing up directly.  The xmodmap sources are pretty trivial here.

Hmm, the current approach uses xmodmap too.  This is going to screw with the
capplet.  The first time a key is assigned it won't have a keysym and will
display as a keycode then modmap a sym.  When the user reruns the capplet it
has a name (for the keys we handle)

Let me ask the question from a different direction.  Why do we need to bind
those keys directly ?  It is only done for a few of the multimedia keys
Comment 6 Bastien Nocera 2004-04-08 10:13:50 UTC
Excerpt of the conversation with Jody, who has a very fair point:
<jody> the capplet communicates with the settings daemon via strings in gconf
<jody> the settings daemon is what makes the changes
<jody> when a user hits the 'play' key the first time
<jody> the capplet calls eggaccel* to look up the logical name of the key
<jody> it fails to find a keysym and returns 0xae or something
<jody> we set that in gconf
<jody> the settings daemon gets notified and loads the string '0xae'
<jody> assigns a keysym of 'XfreePlay' to that
<jody> user clicks on the entry again or reruns the capplet
<jody> The capplet needs a display string for the key
<hadess> and play will be assigned to play?
<jody> yup, it now has a name

I believe that gdk_keymap_translate_keyboard_state() shouldn't send back keysyms
that aren't GDK keysyms in the eggaccel* functions.
Comment 7 Jody Goldberg 2004-08-09 19:45:20 UTC
I'm advocating a simpler approach to solving this that will avoid attempting to
store the old keybindings (and keeping that store in sync with the server). 
Lets just add a test at the ui level to disable assigning a key with existing
keysyms to the special modmap managed keys.  This is by no means perfect

1) setting directly from gconf will still screw things (not a big problem)
2) We'll want to be careful not to display an error message when assigning the
same key again now that it has a keysym.

Failing that we can either ignore the problem (which has worked to date) or
ditch the functionality until post 2.8.
Comment 8 Frederic Crozat 2004-10-08 16:07:23 UTC
*** Bug 148969 has been marked as a duplicate of this bug. ***
Comment 9 Frederic Crozat 2004-10-08 16:08:28 UTC
Mdk bug for this :
Comment 10 Kannan Goundan 2004-10-09 07:53:25 UTC
Additional info from duplicate Bug 148969:

If I bind "WinKey+Z", then even plain "Z" triggers the shortcut.  I can no
longer type the letter "Z".

(let me know if mentioning this wasn't necessary).
Comment 11 Michal Bukovjan 2004-12-04 17:24:09 UTC
*** Bug 154940 has been marked as a duplicate of this bug. ***
Comment 12 Sebastien Bacher 2005-01-05 20:17:17 UTC
*** Bug 162904 has been marked as a duplicate of this bug. ***
Comment 13 Sebastien Bacher 2005-01-06 00:42:24 UTC
a debian bug similar to #162904:

"I want to be able to pause/play my music by typing ctrl-alt-p. However whenever
I use the gnome-keyboard-settings to do this. It doesn't work. The p key never
gets through. I have to undo the setting and kill/restart gnome-settings-daemon
to be able to use the p key again.
This was not a problem when setting lock screen to ctrl-alt-l I do not know what
is causing the problem, but I am willing to help debug. This happens for 'r' =>
'Previous track' and 'n' 'Next track' as well. 'o' => 'Volume Down' and 'u' =>
'Volume up' work fine."

Bastien, do you think you can fix that for GNOME 2.10 ?
Comment 14 Luis Villa 2005-01-24 22:04:37 UTC
I'm tentatively marking this a 2.10 showstopper; we should generally refuse to
ship bugs that force people to log in/log out or worse.
Comment 15 Elijah Newren 2005-01-26 18:37:59 UTC
*** Bug 154297 has been marked as a duplicate of this bug. ***
Comment 16 Elijah Newren 2005-02-28 01:48:35 UTC
According to,
this won't be fixed for 2.10; punting to 2.12.
Comment 17 Elijah Newren 2005-05-21 15:32:42 UTC
*** Bug 304999 has been marked as a duplicate of this bug. ***
Comment 18 Luis Villa 2005-07-10 04:38:58 UTC
Embarassed this is still in 2.12 :/
Comment 19 Nigel Tao 2005-08-18 17:28:45 UTC
*** Bug 164279 has been marked as a duplicate of this bug. ***
Comment 20 Daniel Holbach 2005-09-20 20:28:44 UTC
i'm not quite sure how the state of the bug is? i suppose the patches are out of
Comment 21 Allison Karlitskaya (desrt) 2006-01-07 00:44:31 UTC
*** Bug 325865 has been marked as a duplicate of this bug. ***
Comment 22 Elijah Newren 2006-01-11 05:26:04 UTC
Can someone verify whether this still happens with the 2.13.x development series so we can decide whether to bump the version to make sure it doesn't get overlooked in bugsquad blocker reviews?
Comment 23 Luis Villa 2006-01-11 13:07:24 UTC
Yeah, this is still the case. I'm about to have to log out and back in again to get the letter p back. [Used copy and paste to get these.]
Comment 24 Bastien Nocera 2006-01-11 13:26:14 UTC
Luis, I don't think you tested that properly.
The problem was that most of the media keys (Play, Pause, etc.) were not filtered by the "acme" part of g-s-d, but simply mapped an xkeysym to the keycode using xmodmap.

g-s-d doesn't call xmodmap to bind single keysyms anymore, and expects the keyboard (xkb and co.) to already set those up.

With the current code, you should be able to get your key back by pressing "Backspace" after having clicked to change the keybinding.

The only thing left to be done is to remove the "Media" keys (those that use to be bound to keysyms instead of caught and acted upon) from the keybindings capplet.
Comment 25 Bastien Nocera 2006-01-11 13:30:46 UTC
I didn't read it properly. The multimedia keys still has that crap in, patch to remove those coming.
Comment 26 Bastien Nocera 2006-01-11 13:35:30 UTC
Created attachment 57153 [details] [review]

Remove the keysym binding crap in the multimedia keys handlers.
Comment 27 Steve Frécinaux 2006-01-11 13:35:46 UTC
(In reply to comment #23)

BTW, Luis, you can bring back your keys by going in the Keyboard Preferences and double-clicking on your usual layout in the Layout tab.

This won't fix that bug, but you won't have to logout :-)
Comment 28 Bastien Nocera 2006-01-11 13:50:03 UTC
*** Bug 143000 has been marked as a duplicate of this bug. ***
Comment 29 Bastien Nocera 2006-01-11 13:55:40 UTC
*** Bug 135476 has been marked as a duplicate of this bug. ***
Comment 30 Sebastien Bacher 2006-01-11 15:11:00 UTC
patch commited, thanks
Comment 31 Crispin Flowerday (not receiving bugmail) 2006-01-21 17:29:47 UTC
So how exactly do I now bind the play / pause / next / prev keys on my keyboard ?
Comment 32 Bastien Nocera 2006-01-21 20:09:17 UTC
Crispin, the code was removed because it could cause huge problems. I didn't take into account modifiers, and it couldn't restore the key properly.

You can use xmodmap to set the key by hand, or get the keyboard layout added to Xorg (I guess Sergey would know more about the details than me on that).
Comment 33 Bastien Nocera 2006-01-30 18:43:50 UTC
That patch was reverted.
Comment 34 Sebastien Bacher 2006-02-17 23:19:16 UTC
updating the severity this is an annoying bug but not a stopper for that cycle and will the patch will be applied in the start of next cycle
Comment 35 Bastien Nocera 2006-08-08 08:23:38 UTC
*** Bug 332695 has been marked as a duplicate of this bug. ***
Comment 36 Bastien Nocera 2006-08-08 08:25:16 UTC
*** Bug 341992 has been marked as a duplicate of this bug. ***
Comment 37 Matthias Clasen 2006-08-11 23:53:37 UTC
Can we see some action on this really ugly problem ? 
It causes broken-desktop situations for users (keys stop to work with no 
obvious way to fix)
Comment 38 Ray Strode [halfline] 2006-08-24 18:29:14 UTC
So here's how I understand things...

Rhythmbox (and presumably other apps) watch for specific keysyms: XF86_AudioPlay, XF86_AudioStop, etc. and react to those.  Our XKB keyboard data doesn't have very good coverage for mapping those keysyms to physical keyboard keys so when a user presses the Play key on their keyboard it doesn't generate XF86_AudioPlay.  Bastien's code worked around this, such that if a user explicitly set up a keybinding in the capplet for Play then the settings daemon would run xmodmap to create the mapping between the key the user pressed and the keysym XF86_AudioPlay.  This was a workaround because we don't have good XKB coverage.  It also was a bit buggy.  

For the near term, I think we should just rip that code out and change rhythmbox (et al.) to call XGrabKey on the keycode derived from the keysym saved in gconf for that action by the capplet.  I've heard that muine already does this.

Long term, apps calling XGrabKey at all is a bad idea.  The settings daemon should handle that and we need to work out some sort of protocol for notifying the foreground app the key was pressed.  In this case "foreground" means app currently with the focus or some app specified in Preferred Applications if the currently focused app doesn't participate in the protocol.
Comment 39 Ray Strode [halfline] 2006-08-24 18:36:21 UTC
Also, we need to fix xkeyboard-config to have better coverage of the multimedia keys on keyboards.  Then the user just has to make sure they choose the right model in the keyboard capplet and things should work (even for legacy apps that just call grabkey on the play keysym directly)
Comment 40 Bastien Nocera 2006-08-24 18:50:26 UTC
The latter still sucks though, as applications will be fighting over the grab.
I agree with the other bits, as I discussed this with Ray.
Comment 41 Ray Strode [halfline] 2006-08-25 00:32:05 UTC
Created attachment 71553 [details] [review]
what i built into rawhide

so this is what i built into rawhide. It's pretty similiar to attachment 57153 [details] [review], but it leaves the entries for the multimedia key in the keybinding capplet, expecting apps to handle actually watching the keys.  I guess if this weren't a short term solution, we'd want to use a more app-neutral place in gconf.
Comment 42 Ray Strode [halfline] 2006-08-25 00:45:35 UTC
Created attachment 71554 [details] [review]
add defaults in schema too for the standard keysyms
Comment 43 Bastien Nocera 2006-09-22 13:49:43 UTC
*** Bug 311741 has been marked as a duplicate of this bug. ***
Comment 44 Bastien Nocera 2006-09-22 13:59:26 UTC
*** Bug 351305 has been marked as a duplicate of this bug. ***
Comment 45 Bastien Nocera 2006-09-22 14:13:05 UTC
*** Bug 154944 has been marked as a duplicate of this bug. ***
Comment 46 Stanislovas Mickus 2006-09-22 22:08:32 UTC
We still have this bug in  gnome 2.16 release.
That is, if you for example bind <Shift><Ctrl>p to play, pause, previous, next, stop keyboard shortcut you loose normal behaviour of your key "p". Instead it is linked to the shortcut action and <Shift><Ctrl>p does nothing.
Disabling shortcut in capplet doesn't help it just empties "p" keycode's keysym in  keymap table. To resolve this you have to logoff/login or change back keysym with xmodmap.
Comment 47 Chris Wagner 2006-09-23 14:46:53 UTC
This was recorded in Ubuntu as
Comment 48 André Klapper 2006-10-02 09:17:19 UTC
can i please ask some of the gnomecc developers to take a look at this?

rodrigo, dobey, thomas, sebastien?
this is a major embarrassment that should be fixed within this release cycle and not be postponed again. having to restart the desktop is just ridiculous.

thanks in advance.
Comment 49 André Klapper 2006-10-19 20:24:03 UTC
svu: *ping* - can you please comment on this? thanks a lot in advance!
Comment 50 Ray Strode [halfline] 2006-11-15 05:18:46 UTC
Created attachment 76621 [details] [review]
Don't allow key combinations that probably aren't multimedia keys

So for 2.16, one option might be to disallow key combinations altogether for the multimedia actions, but still allow the users to manually bind their non-modified multimedia keys.  So we would basically only allow single key presses of keys that aren't normal typing keys.

The above patch is a stab at this, but I don't have a multimedia keyboard here to test it, so it might not work.  

Also, I think one improvement to the patch might be to only allow binding to keycodes with either no keysyms or the XF86* keysyms instead of reusing the mega conditional thats already in accel_edited_callback for a different purpose.
Comment 51 Ray Strode [halfline] 2006-11-15 16:58:43 UTC
Created attachment 76654 [details] [review]
Don't allow key combindations that probably aren't multimedia keys and save keycode instead of keysym in gconf

So I played with the patch in attach 76621 a bit this morning when I got to work.  It seems to work okay, for the most part, but one problem I ran into was if I bound Play to the play key twice in a row, the second time it would show up as XF86AudioPlay instead of the keycode.  This is wrong because it means that the next I log in, its going to try bind to XF86AudioPlay which won't exist.

The above patch fixes this by always storing the keycode in gconf for multimedia keys.

Again, this patch is more of a near-term stop gap solution than a real fix.
Comment 52 Jan Arne Petersen 2007-01-02 00:53:20 UTC
Created attachment 79159 [details] [review]
Use D-Bus interface for the multimedia player keys
Comment 53 Jan Arne Petersen 2007-01-04 00:59:47 UTC
Created attachment 79345 [details] [review]
Updated D-Bus interface for the media player keys.
Comment 54 Jan Arne Petersen 2007-01-04 01:02:48 UTC
Created attachment 79347 [details]
A sample plugin for banshee which uses the D-Bus interface defined above.
Comment 55 Rodrigo Moya 2007-01-05 10:02:36 UTC
Patch looks good to me, except for one thing, which is that, instead of starting a new DBUS server, I guess it would be better to reuse the DBUS server that is created in gnome-settings-dbus.c. Could you please update the patch to do so?
Comment 56 Bastien Nocera 2007-01-05 10:33:38 UTC
How do you handle multiple players attaching to the service?

Also, I guess the keys should be using the XF86XXX as the defaults in the schemas file, so that people with non-broken keyboard setups have it working OOB.

Note that as we wouldn't be setting keysyms, we wouldn't need to have any special casing in the capplet.

I would have to do a full-code review before I can approve it though.
Comment 57 Jan Arne Petersen 2007-01-05 12:42:44 UTC
To comment 55:
I'll provide another patch.

To comment 56:
The MediaPlayerKeyPressed signal contains an argument with the last active player.

I could update the patch to contain the schema file changes.

I tried to remove all special casing in the capplet.
Comment 58 Jan Arne Petersen 2007-01-06 18:54:09 UTC
Created attachment 79550 [details] [review]
alternative implementation integrated into the org.gnome.SettingsDaemon interface

A disadvantage of this approach is, that media players couldn't test simply for the existence of the org.gnome.MultimediaKeys interface.
Comment 59 Rodrigo Moya 2007-01-08 16:50:54 UTC
Patch committed
Comment 60 André Klapper 2007-01-08 17:12:38 UTC
patch was committed to trunk, according to rodrigo it cannot be committed to gnome-2-16 branch, because it contains a new feature.

(updating the gnome blocker target to be fuddy-duddy... dumdidum.)