Red Hat Bugzilla – Bug 117221
Overrides ~/.Xmodmap settings
Last modified: 2007-04-18 13:03:45 EDT
Description of problem: gnome-settings-daemon overrides my carefully crafted ~/.Xmodmap settings. There does not seem to exist a way to prevent it; 'gnome-settings-daemon' does no do this setup immediately so that an 'xmodmap ~/.Xmodmap' in the startup sequence will be executed too early. Version-Release number of selected component (if applicable): control-center-2.5.3-1 How reproducible: 100% Steps to Reproduce: 1. create an ~/.Xmodmap file; e.g. with | keycode 66 = Control_L | keycode 37 = Caps_Lock 2. start gnome resp. gnome-settings-daemon Actual results: Left-ctrl & caps-lock are _not_ swapped Expected results: Left-ctrl & caps-lock are swapped
still with control-center-2.5.4-1 With this version things are yet more worse: I get everytime an annoying messagebox saying that ~/.xmodmap will be overridden.
still with control-center-2.6.1-3
Seems to me that the following bugs may be are dupes of this. Bug 119295 Bug 120017 Bug 121183 Bug 121398 Bug 124070 BTW: With some help by http://linuxtoday.com/infrastructure/2004061100926OSHWHL I was able to merge my old xmodmap hack to xkb. Maybe this is helpful to others. But maybe someone who knows more of the details could tell us if it's a feature or a bug....
It is a bug in control-center; my ~/.Xmodmap is completely valid and worked before. After executing 'xmodmap ~/.Xmodmap' manually, things are fine. xkb is not an option since theses settings can be done by the administrator only, but ~/.Xmodmap is a user setting.
Enrico, I don't know more than you and also think Xmodmap should work. Someone has (maybe for a good reason?) added this: $ grep "play" /etc/X11/xinit/xinitrc # xkb and xmodmap don't play nice together Maybe somebody could clarify this and infom us how we can avoid xmodmap and use xkb for the same things... BTW: Also this was addec for User settings -- but I currently don't know how to use it ;-) $ grep userxkbmap /etc/X11/xinit/xinitrc userxkbmap=$HOME/.Xkbmap if [ -f "$userxkbmap" ]; then setxkbmap `cat "$userxkbmap"`
This has really nothing to do with interaction of xkb and xmodmap E.g. remove gnome-session and use plain 'twm' --> keys are working as expected. Then, when you execute /usr/lib/gnome-settings-daemon the keyboard (and your ~/.Xresoures) will be the complete crap again. It is caused by the ignorance of the Gnome developers who think that they know everything and the user nothing. A solution for this problem would be to throw away the braindead Gnome HIGs and to allow the user to configure his system again. Examples would be checkboxes like '[ ] Override ~/.Xmodmap settings' or '[ ] Override ~/.Xresources' in the gnome-*-properties dialogs. Or to split 'gnome-settings-daemon' into several programs (one per configured resource) which could be removed by '%triggerin control-center' scripts of a local rpm.
*** Bug 119295 has been marked as a duplicate of this bug. ***
Xmodmap *DOESN'T* play nice with Xkb. There is a huge amount of complexity in the XKB extension to make things sort of work, but it's still at a 90% level where weird interactions leak out the corners. The reason that gnome-settings-daemon ends up overriding your Xmodmap is that gnome sets the keyboard map based on user preference. (gnome-keyboard-properties.) If someone wants to try and figure out how to make it not set the keyboard map if it's "the same" as the system map, that's potentially one fix. I can't see adding a checkbox to turn off bits of gnome-keyboard-properties; it's far too complex as it is. A hidden GConf key might be possible. What I'd really love here is a simple xkeycaps style application that did the right thing for XKB; it could allow saving keyboard layouts for other users in much a similar way to gnome-theme-manager.
The problem is that the Gnome keyboard settings affect non-Gnome environments. E.g. although Gnome is not my userinterface I have to execute 'gnome-settings-daemon' to activate suitable fonts for gtk2 applications. But 'gnome-settings-daemon' overrides lot of non-Gnome related settings (~/.Xmodmap + ~/.Xresources) and there is no way to prevent it. My suggestions: * check if ~/.Xmodmap or ~/.Xresources exist and give out a dialogbox asking whether these settings shall be overridden. * test if gnome-settings-daemon will be executed through 'gnome-session' or by manual invocation. In latter case, setup only the Gnome specific options but not global ones.
still with control-center-2.8.0-12
xmodmap has been depricated for a while now. If you want to swap CTRL and capslock do the following: -startup gnome keyboard prefs -goto the layout options tab -expand controlkey position -select swap control and capslock -press close -be happy If you want something more exotic, please explain what and why. Also note that the above settings are not gnome-stuff but are a nice UI over nightmarish kxb config options. I know how nightmarish xkb is because: -I want my left alt to be the start of compose sequence key. Using the gnome dialog is so much better then doing it with xkb config statements in xorg.conf -I've written a program which controles the keyboard leds, in order for a program to get control over the keybleds one needs to dig deep into xkb (to deep, I've never been sane after :)
In my case it's been that in my laptop, the left shift is a small normal-sized key, with another key labled "#" and "~" next to it. I like to use xmodmap (or whatever) to make this extra key to behave like left shift too.
I would like to avoid Gnome2 as far as possible. So configuring my keyboard settings through Gnome2 is not an option for me. What is with people with other desktop environments (e.g. KDE)? Most of these DE have their own keyboard setup (which can be turned off in an userfriendly way); why should they want to use Gnome2 to set it up? And, since when is ~/.Xmodmap deprecated? It is a small file which can be transfered to other machines without having unwanted sideeffects (which might be occur by exporting registry trees from gconf).
About xmodmap being deprecated, this has been the case since the introduction of xkb, which is needed for proper internationalisation support. As said this has unintented interactions. About the #~ key next to the shift, very tricky one. What does the OS the laptop was designed for (see the designed for sticker :) do with this key if anything? What you want can be done with xkb but requires editing of xkb config files, this can then be made an option, but how common is this?
It's a UK model. This things are normal in European models. So, I think it should be more common than being just me, but not about this particular key definitely.
'Red Hat Raw Hide' refers to the development tree for Red Hat Linux. Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Red Hat apologizes that these issues were not resolved in a more timely manner. However, we do want to make sure that important don't slip through the cracks. If these issues are still present in a current release, such as Fedora Core 5, please move these bugs to that product and version. Note that any remaining Red Hat Raw Hide bugs will be closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Closing as CANTFIX.