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 590032 - race condition vs. xmodmap (for keybindings) when logging in
race condition vs. xmodmap (for keybindings) when logging in
Status: RESOLVED DUPLICATE of bug 565540
Product: metacity
Classification: Other
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2009-07-28 16:28 UTC by Allison Karlitskaya (desrt)
Modified: 2009-11-20 21:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Allison Karlitskaya (desrt) 2009-07-28 16:28:22 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.
Comment 1 Owen Taylor 2009-11-20 21:34:50 UTC
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 ***