Bug 117221 - Overrides ~/.Xmodmap settings
Overrides ~/.Xmodmap settings
Product: Red Hat Raw Hide
Classification: Retired
Component: control-center (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Ray Strode [halfline]
: 119295 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-03-01 14:47 EST by Enrico Scholz
Modified: 2007-04-18 13:03 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-18 15:41:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2004-03-01 14:47:25 EST
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):


How reproducible:


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
Comment 1 Enrico Scholz 2004-03-15 14:31:36 EST
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.
Comment 2 Enrico Scholz 2004-05-19 18:47:24 EDT
still with control-center-2.6.1-3
Comment 3 Thorsten Leemhuis 2004-06-11 18:23:44 EDT
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
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.... 
Comment 4 Enrico Scholz 2004-06-11 18:37:09 EDT
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.
Comment 5 Thorsten Leemhuis 2004-06-12 02:35:42 EDT
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
if [ -f "$userxkbmap" ]; then
    setxkbmap `cat "$userxkbmap"`
Comment 6 Enrico Scholz 2004-06-12 14:10:54 EDT
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.
Comment 7 Mike A. Harris 2004-09-21 05:30:21 EDT
*** Bug 119295 has been marked as a duplicate of this bug. ***
Comment 8 Owen Taylor 2004-09-21 10:34:57 EDT
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.
Comment 9 Enrico Scholz 2004-09-21 14:25:37 EDT
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

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.

Comment 10 Enrico Scholz 2004-12-22 06:31:52 EST
still with control-center-2.8.0-12
Comment 12 Hans de Goede 2005-06-09 13:12:01 EDT
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 :)
Comment 13 Behdad Esfahbod 2005-06-09 13:31:44 EDT
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.
Comment 14 Enrico Scholz 2005-06-09 13:38:09 EDT
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).
Comment 15 Hans de Goede 2005-06-09 14:10:57 EDT
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?
Comment 16 Behdad Esfahbod 2005-06-09 14:14:07 EDT
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
Comment 17 Bill Nottingham 2006-08-07 22:03:08 EDT
'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

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.
Comment 18 Bill Nottingham 2006-10-18 15:41:52 EDT
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

Closing as CANTFIX.

Note You need to log in before you can comment on or make changes to this bug.