GNOME Bugzilla – Bug 590032
race condition vs. xmodmap (for keybindings) when logging in
Last modified: 2009-11-20 21:34:50 UTC
this is very easily not a problem with metacity. maybe gnome-session or something... i have a keyboard with some keys that are not recognised by X. so i made a shellscript called 'xmodmap' and tossed it in my home directory that would run xmodmap commands to assign the proper key symbols to the raw keycodes (F13 through F19 on an apple keyboard, for what it's worth). the idea is that i would manually run this with the shell when i needed to. it sucked, but it was a first step. surprisingly, next time i logged in i got this helpful dialog offering to import this file as an xmodmap file. i guessed maybe it saw that the file ended with 'modmap' so i tried renaming it to '.fkeys-modmap' as a somewhat more permanent solution. that worked and now it gets loaded every time i login. that's totally awesome. the problem is this: i bind some of these keys in metacity and (presumably depending on the exact order that things get loaded on login) my keybindings end up working only about 50% of the time. i guess how metacity works for keybindings is that on startup it looks at the gconf database and parses the text strings ("<Ctrl>F19" and such) into numeric values. if the xmodmap has not occurred at this point then the X server doesn't know what an F19 is and this fails -- no binding. i guess the solution to this problem involves one or more of the following: 1) metacity somehow monitors the X server for the keyboard map being modified and retries parsing the text strings when this happens 2) metacity gets started after the xmodmap step is definitely complete for now, in the event that i get "unlucky" i just manually run 'metacity --replace' when the login is complete.
Not completely sure of this duplicate marking, since I don't fully know how the xmodmap compatibility code works within GNOME, but looks like the same issue. *** This bug has been marked as a duplicate of bug 565540 ***