GNOME Bugzilla – Bug 133815
keys refuse to "unbind"
Last modified: 2007-01-08 17:12:38 UTC
From: Debian User <> To: submit@bugs.gnome.org 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? Always Additional Information: The only fix seems to be ctrl-alt-backsace
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.
Created attachment 25728 [details] [review] patch for acme
The same patch for the control-center below. Jonathan and Jody will decide if it's worth adding for GNOME 2.4.
Created attachment 25729 [details] [review] restore the original keysym when unbinding a key
Ick! 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
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.
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.
*** Bug 148969 has been marked as a duplicate of this bug. ***
Mdk bug for this : http://qa.mandrakesoft.com/show_bug.cgi?id=12022
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).
*** Bug 154940 has been marked as a duplicate of this bug. ***
*** Bug 162904 has been marked as a duplicate of this bug. ***
a debian bug similar to #162904: http://bugs.debian.org/288855 "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 ?
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.
*** Bug 154297 has been marked as a duplicate of this bug. ***
According to http://mail.gnome.org/archives/desktop-devel-list/2005-February/msg00034.html, this won't be fixed for 2.10; punting to 2.12.
*** Bug 304999 has been marked as a duplicate of this bug. ***
Embarassed this is still in 2.12 :/
*** Bug 164279 has been marked as a duplicate of this bug. ***
i'm not quite sure how the state of the bug is? i suppose the patches are out of date?
*** Bug 325865 has been marked as a duplicate of this bug. ***
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?
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.]
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.
I didn't read it properly. The multimedia keys still has that crap in, patch to remove those coming.
Created attachment 57153 [details] [review] gcc-no-keysym-binding.patch Remove the keysym binding crap in the multimedia keys handlers.
(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 :-)
*** Bug 143000 has been marked as a duplicate of this bug. ***
*** Bug 135476 has been marked as a duplicate of this bug. ***
patch commited, thanks
So how exactly do I now bind the play / pause / next / prev keys on my keyboard ?
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).
That patch was reverted.
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
*** Bug 332695 has been marked as a duplicate of this bug. ***
*** Bug 341992 has been marked as a duplicate of this bug. ***
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)
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.
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)
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.
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.
Created attachment 71554 [details] [review] add defaults in schema too for the standard keysyms
*** Bug 311741 has been marked as a duplicate of this bug. ***
*** Bug 351305 has been marked as a duplicate of this bug. ***
*** Bug 154944 has been marked as a duplicate of this bug. ***
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.
This was recorded in Ubuntu as https://launchpad.net/distros/ubuntu/+source/control-center/+bug/40747
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.
svu: *ping* - can you please comment on this? thanks a lot in advance!
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.
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.
Created attachment 79159 [details] [review] Use D-Bus interface for the multimedia player keys
Created attachment 79345 [details] [review] Updated D-Bus interface for the media player keys.
Created attachment 79347 [details] A sample plugin for banshee which uses the D-Bus interface defined above.
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?
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.
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.
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.
Patch committed
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.)