GNOME Bugzilla – Bug 143487
gnome-settings-daemon unconditionally kills changes made with Xmodmap
Last modified: 2005-02-02 01:00:40 UTC
1) Make a valid .Xmodmap that changes ANYTHING. 2) Run gnome-settings-daemon. 3) Close dialog that makes vague and unclear hints that it may be possible to change the setting-eating behavior. gnome-settings-daemon kills any changes made to the keymap with Xmodmap. Always. Do not pass go. Do not collect $200. Since it is necessary to spawn gnome-settings-daemon in order for GTK2 applications to use the configured fonts, I'm stuck doing something like this in my .xsession: gnome-settings-daemon & sleep 1 xmodmap ~/.Xmodmap This is a miserable hack and race condition at best, without even going into the joys of putting 'sleep 1' in my xsession. I would be content with a gconf key to disable any keymap mangling. I do not use GNOME (although I do use some GNOME applications), and I would therefore prefer it did NOT unconditionally destroy settings it doesn't have the capabilities to replace.
I won't pretend to understand this, but marking as new so that someone familiar with xmodmap and so on can look at it and decide what's to be done.
I've been hit by this bug, too. I've got three alternative proposals for a solution: 1. let ~/.Xmodmap override the keyboard layout set by gnome-settings-daemon 2. enhance the Keyboard Preferences / Layout Options tool so that you can provide your own customizations 3. provide detailed instructions about how to create new layout options (if they are not hard-coded; I couldn't find out if they were) Currently GNOME 2.6 won't let me easily do my favorite customizations for the default Finnish layout: - use the Caps Lock key for Select (keycode 66, keysym 0xff60, Select) - use the US layout for the two bracket keys between P and Enter
Glyph Lefkowitz has written about this bug in his weblog [1]. Here are a couple of hacks he tried but which didn't work: "...I thought that I would use the "sessions" control panel to run a command upon login, at the right point (after the session manager proxy but before my window manager). No dice! This hangs the login process with no debug information, as it appears to be infinitely attempting to restart the xmodmap program and waiting for it to map a window." "...can't run ~/.xmodmap in my ~/.xsession, because gnome-smproxy resets both any system-wide or any local xkb configuration changes. I think. I also couldn't find any documentation of this anywhere on short notice." [1] http://www.livejournal.com/users/glyf/17313.html
We agree that it's a problem The core of the issue is that XKB just does not get along with modmap. I'm working on a solution that will get back ported.
Just to add a data point: I just wasted 2h real-world time for coming to the same conclusions and finally finding this bug here. Please get .xmodmap back to work as soon as possible. Surely there must be a simple workaround, like running xmodmap in/after the keyboard-tool? Cheers, Volker
Chiefly putting my vote into this, too. Even though I've spent only half an hour finding this bug, I am overly annoyed at yet another one of my long-standing configurations getting broken. It feels like a straitjacket to have no result from keypresses I use about ten times a minute. And I don't quite see how xkb and xmodmap don't go along. For me, xkb has always been the base setup, and xmodmap something that I can run on top of that to fine-tune things individually. But then, `xkb' for me means `/usr/lib/X11/xkb'. Well, looks like I'll have to really grok xkb tables after all, in order to be able to use those spiffy newby graphical keyboard settings. Just for the record, here's what I had configured: On a (Mitsumi) Apple Extended USB keyboard, Meta on Apple keys (the most frequently used Emacs key more close by) Super on Alt keys (the sawfish window key a little further off, and several useful viewport(oops,read`workspace')-commands bound to W-something) Ctrl and Caps lock swapped (at least that didn't get broken) Multi/Compose on Shift-Control_R (a SuSE linux tradition, and I don't have any of the proposed alternative keys to spare)
The simplest workaroung is ... disable XKB completely. In xorg.conf. I think it should help. The problem happens when you have xkb enabled and trying to use xmodmap. Do not do it:)
Due to the number of people this is hitting, and killing the configurations of, I don't think it's justifiable to move this to "Minor" priority.
OK, Andrew, let's leave it as "major":) Felix: GNOME xkb configuration (by g-s-d) happens after .xmodmap was applied. So all the tweaks from .xmodmap are lost at this point. The only possible solution would be to reapply .xmodmap every time xkb is configured. There is possible drawback here - user can tweak keyboard to death with his .xmodmap - and we cannot control this process at all. Current situation at least guarantees user has exactly the configuration stored in gconf - no more, no less.
I'd like to point out that a solution that only reinstalls ~/.Xmodmap after changing the XKB layout won't always cut it. I use shell scripting in ~/.xsession to put together a suitable modification of the keymap based on various criteria. The possibility to run a script with arbitrary code is therefore needed. That would actually be nicer than an option that simply disables the Gnome XKB stuff altogether, since it would allow advanced users to customize their keymaps and still make use of the fancy language switching stuff (the script would be executed every time the keymap is replaced).
Actually, AFAIK Jody is working on something of that kind. Not sure though. Anyway - I added a hook in g-s-d which is called after each keyboard reconfiguration. Jody is going to piggiback it...
I let gnome execute a shell script that does xmodmap $HOME/.xmodmap , also a very ugly hack. Why does gnome disable xmodmap, also in the alert gnome gave me was written that keymap can be changed somewhere in the control center, but i couldnt find out where. I use a swiss-german keyboard with us layout, which makes one key dead. I used this one to write german umlauts like ä, ö, ü, so i really need xmodmap (or a comparable gnome function) elitepenguin 4t[nospamm]gmx.net
*** Bug 153226 has been marked as a duplicate of this bug. ***
*** Bug 145505 has been marked as a duplicate of this bug. ***
Attaching a patch.
Created attachment 36252 [details] Proposed patch
Comment on attachment 36252 [details] Proposed patch Two issues. 1) While it's good that you honour the "don't ask again" flag. That is only a partial solution. The dialog should only appear if there are modmap files found that are not already listed. 2) /usr/lib/X11/etc/xmodmap.std is not a standard file. why do you need that ?
Another BIG thing. You piggyback gnome_settings_keyboard_xkb_chk_lcl_xmm - which is called only once, at startup. So if at some point later I call g-s-d and change XKB configuration - the settings are not going to be applied after XKB settings. I SPECIALLY introduced PostActivationCallback for a things like this. Could you please use it instead - and move this functionality to the separate .c file if possible (just for the maintenance simplicity). Thanks.
Jody: I didn't find any way to unset the keybindings. So, while the user removes the modmap file from the list I am running the xmodmap command on file ' /usr/lib/X11/etc/xmodmap.std' so that the keboard setting will become default one and once again I am running the xmodmap command to the listed files (loaded files only). Could you please tell me the standard xmodmap file so thae I will use that one? I will do the necessary changes which will bring the dialog when there are some modmap files which are not already listed. Sergey: I can move this functionality to a separate .c file but I didn't get what to do with PostActivationCallback ? Could you please describe it a bit more so that it will be easier to understand?
shakti : you do not need to worry about removing things. The state gets wiped every time the XKB settings get reloaded and given that we're just selecting what to load at startup there is no need to worry about reseting things. What sergey means with the PostActivationCallback is that you should not be loading these modmap files directly. Their impact will be cleared out when XKB reloads. What you need to do is to hook a callback to the xklavier hook to define a PostActivationCallback. That way the files will be reloaded each time XKB resets. I'd like to get this in shortly for testing.
Created attachment 36498 [details] Modified patch
I have used a separate .(c/h) file. Still I am calling this functionality in the startup. I didn't get the idea how to use PostActivationCallback. I need some more clue/pointer here.
shakti, there is a function gnome_settings_keyboard_xkb_set_post_activation_callback. You have to call it at some point in gnome-settings-daemon.c (probably in gnome_settings_daemon_new) - before calling gnome_settings_keyboard_xkb_init. As a first parameter, pass your own callback, as a second one - whatever you need.
shakti : any progress on this ? I'd like to get it into a release.
Created attachment 36592 [details] better patch Now it works fine. I tested it with creating with .xmodmaprc file. Needs review.
Comment on attachment 36592 [details] better patch <jody> it still looks like it comes up unconditionally <sp_> if it is the case, then we have to maintain the list of modmap files available in the HOME directory so that we can compare if some modmap files created newly. <jody> yes, exactly. <sp_> there is a check and it returns from there if the user checked "Not to display the dialog" <jody> yes, but if the user does not select that we still shouldn't display the dialog every single time <sp_> so, it won't display the dialog every time <jody> Only when necessary <jody> The key use case that we want to cover is the first run This is an improvement, but still needs work. As discussed we do not want the dialog to appear every time. <jody> A user with no modmap files <jody> will not have the "don't ask me" set <jody> but we should not display the dialog
Created attachment 36637 [details] updated patch
- Now the dialog comes only in the first login if modmap files exists in the $HOME directory. - The dialog also comes if a new modmapfile exists in the $HOME directory. - As Sergy said, the functionality are implemented in separate files (for maintenance simplicity).
Comment on attachment 36637 [details] updated patch - I think 'known' would be better than 'available' for the gconf key - avoid writing == TRUE - Check the life cycle for 'file_list' I think it is leaking - there's no need to test to see if any files exist, then check again if any new files exists
Created attachment 36673 [details] [review] More refined patch - Used 'known' instead of 'available' - Using == TRUE is avoided. - file_list and its members are freed. - Now it checks only for new files exist or not. Thanks to Jody and Sergey for their help.
For me this looks generally ok. Shakti, did you run g-s-d with valgrind?
I didn't run g-s-d with valgrind. I never used it before. Is it possible for someone to test it with valgrind?
shakti: What I usually do (though it makes the startup VERY slow), is replacing g-s-d with the script: #!/bin/sh exec /usr/bin/valgrind --leak-check=yes --log-file=/tmp/vggsd.log --tool=memcheck /usr/libexec/gnome-settings-daemon.binary $* And then just look into /tmp/vggsd.log...
Comment on attachment 36673 [details] [review] More refined patch Looks good. I'm going to get this into cvs.
It appears you didn't cvs add the new files--they don't appear in cvs.
I did so (with Kjartan's approval).