14.1: ~/.Xmodmap Not Implemented When X Starts; Fails During Use
 

This started a couple of weeks ago and has never before happened in 17 years of running linux and the X Window System.

~/.Xmodmap:
remove Lock = Caps_Lock
remove Control = Control_L
keysym Control_L = Caps_Lock
keysym Caps_Lock = Control_L
add Lock = Caps_Lock
add Control = Control_L
keysym Alt_L = Meta_L Alt_L

In ~/.bashrc are the lines:
if [ -n $DISPLAY ]; then
/usr/bin/xmodmap ~/.Xmodmap
fi

In ~/.xinitrc are these lines:
usermodmap=$HOME/.Xmodmap
/usr/bin/modmap $HOME/.Xmodmap
userresources=$HOME/.Xresources
sysresources=$HOME/.Xresources
sysmodmap=$HOME/.Xmodmap

Despite all this, .Xmodmap key swaps are not happening when I run 'startx' (for xfce4). Worse, now the bindings are lost at random times while I'm working in an X app or virtual terminal.

My Web searches find others with this problem (on Slackware and other distribuitons) but their solutions are not resolving the problem here. Please suggest what might be causing this behavior and how I can fix it.

TIA,

Rich

I'm having this same issue, and the other day my wife complained she cannot do äöü any more. It started with some Xorg upgrade. We probably should file a bug at x.org (if it is not opened yet).

Using ~/.Xmodmap (to swap Esc and Caps/Lock) in Slackware 14.1 works fine here, but loading of that file is done in my xinitrc, not my bashrc (or zshrc, for that matter). My xinitrc (obviously for the i3 WM) looks like that:

Are you sure you're not switching them twice and ending up back where you started?
I'd take those lines out of your ~/.bashrc and see if that fixes the issue.

I intially had the command for xmodmap only in ~/.xinitrc. I added it to ~/.bash_profile and the if statement in ~/.bashrc because those seemed to have worked for others when I searched the Web.

I can remove (or comment out) the extras and see if the system returns to normal. As I typed this last sentence, the key swapping was lost again. It would be nice to figure out what is causing this behavior since it does not appear on any other host on the LAN nor has it happend before on this or any other system I've had.

Might there be a log file with information on this? It's a frustrating situation and needs to somehow be resolved.

Thanks, all of you,

Rich

I do not think the problem lies in executing xmodmap when X is started. Sometimes X comes up with custom keymap loaded, sometimes not. Sometimes custom mapping is lost during X session. What does the above tell to you? That there is some issue with Xorg.

I would be looking closer at the desktop environment for the source of the problem.

DE runs on top of X, what has it to do with core functions provided by X? I'm running bare Openbox, BTW. OP is running Xfce.

Openbox also does it's own keymappings.

EDIT:
So xmodmap sets the keymap, right? I can see the argument if xmodmap is messed up somehow. That's not what I'm hearing. It's that something after the xmodmap is messing up the keymappings, or maybe I misunderstood. There COULD be a problem with core X, but I would eliminate the top layer (DE, WM, XAP), then look at extensions like XKb before trying to find this in either the server or the protocol libs. I will try to think of a way to trace this... but it will not be tonight as I am too tired to start researching where I should start (also most of my coding for X has been about xrandr and xinerama). But if no one figures this out before I get time, I will give a shot.

Theoretically it is possible, both Openbox and Xfce suddenly started reconfiguring X keymaps. But what are the odds?

Good point. Like I said in my ealier EDIT, I will work on a small app that somehow traces what happens per keyboard and mappings, but I won't start until at least tomorrow evening.

EDIT:
One point though, with .Xmodmap files like the op's, each time xmodmap is run with that .Xmodmap file as arg, most of those settings just get reversed. At least the Caps_lock and Control_L part just reverses it self on each invocation. I guess the thing to do is to setup a system wide alias or wrapper for the xmodmap executable that logs as much information as relavent when called. A script wrapper would be enough... rename /usr/bin/xmodmap to /usr/bin/xmodmap.bak, put the wrapper in it's place. Would be easier than writing the C code like I was thinking about.

Well, interesting find. If running xdm, it runs the users ~/.Xmodmap as part of it's session startup. So if you have a line in ~/.xsession or ~/.xinitrc that runs xmodmap, then xmodmap will be run twice. I will have to investigate other greeters. The pertinent xdm startup file is /etc/X11/xdm/Xsession.

I'm still having this problem. Let me try to clarify the situation here.

-- I don't use a GUI login; I log into a console then run 'startx' which is an alias for start xfce4.
-- The command 'xmodmap ~/.Xmodmap' has been in ~/.xinitrc with both Red Hat (4.0-7.0) and Slackware (8.0-14.1).
-- It has always worked as intended until a few weeks ago.
-- This is the only host (of 3 hosts on the LAN) with this issue; all run xfce4 and Slackware-14.1.
-- The only difference among the 3 hosts is that this one runs the 32-bit version for historical and practical reasons (e.g., I don't need 64-bit capabilities on this host).
-- While xmodmap apparently does not read and invoke the key mapping changes when X is started via ~/.xinitrc, manually running it in a virtual terminal always works.
-- For a while last week, the key mapping would be lost one or more times during the day. That no longer happens. As soon as the X Window System starts I manually run xmodmap and the mapping is stable through the time I kill X and log off.

Do these details provide any clue about what might have broken when I startx?

Thanks,

Rich

According to your first post you are using the xmodmap command in your ~/.xinitrc and your ~/.bashrc. Is this still the case?

I unpacked all xfce related packages into a temporary directory. Then I ran
here's the results:
Clearly, there is a good chance that xmodmap could be, and probably is, called twice.

I understand your frustration. I set up a ~/.Xmodmap file. It get's loaded twice if I add a line in .xinitrc that runs xmodmap to load it. This happens both from text terminal login + startx, as well as my usual xdm login. I don't use a desktop environment, so the first call to xmodmap is somewhere in the system X startup scripts. When I remove/comment the xmodmap line in my ~/.xinitrc, then xmodmap only get's called once.

I've checked the slackware64-14.1 and slackware-14.1 directories at ftp://ftp.slackware.com/pub/slackware. The only changes this year to any X related packages are cairo in February and libXfont in January. I can't see how this could have started two weeks ago. So it worked before? What changed? Curse me for saying it, but the change is most likely on your end. I'm trying to help, but frankly, it sounds to me like a problem with xmodmap being called multiple times, each call reversing the affects of the last; given your .Xmodmap contents, that is exactly what would happen.

My suggestion is to comment out all lines in your .xinitrc/.xsession/.bashrc that run xmodmap (anything that runs xmodmap that is in your $HOME dir).
Leave your ~/.Xmodmap file intact. Then see where you stand as far as key mapping after starting X.

Just a suggestion.

Over and out.

EDIT:
I apologize for my tone in this post. I generally try to keep my bad moods to myself. You've don't deserve it. My bad day elsewhere shouldn't have shown through at you or here at all.

I am wondering whether these sections from the /usr/bin/startxfce4 script are applicable here.
and then later
and from /etc/xdg/xfce4/xinitrc
As I read it, if $XDG_CONFIG_HOME is not set and there is no ~/.config/xfce4/xinitrc, then /etc/xdg/xfce4/xinitrc is run. If ~/.Xmodmap is present, then xmodmap is run a second time after being initially run from ~/.xinitrc via startx.

This would make this problem specific to xfce.

No, it isn't. Only ~/.xinitrc contains the xmodmap command.

Rich

allend, j_v, et al.:

All of you provided me with places to look for the problem. I _think_ that I found and solved it. Just killed X and restarted it and ~/.Xmodmap was correctly implemented by /usr/bin/xmodmap.

For some reason there was another call to 'xmodmap ~/.Xmodmap' in ~/.config/xfce4/xinitrc. When I commented that out the problem went away. When and how that command was seen and run I've no idea. Since there's ~/.xinitrc I never went looking for another file with the same name. Regardless of the reason, it appears that the system was invoking xmodmap twice and the second time cancelled the changes of the first time.

Thanks again to all of you,

Rich

I'm glad you were able to track it down. This is a very insidious problem, especially when coupled with the layers of scripts involved in getting both X11 and a modern desktop environment up and running. There has been at least one other thread that addresses keymapping failure in a different desktop environment. Given your succes, I will try to find that thread again.

Cheers,
John

John,

What makes this more insidious is that it did not occur after a deliberate change. That is, I upgraded to -14.1 several weeks before this behavior suddenly appeared, and other than a couple of upgraded patched packages, the system behaved normally. Then, for a few days, the key mappings would change back in the middle of the day when I was working either in a virtual terminal or a GUI app.

When the behavior is inconsistent and cannot be associated with a specific, deliberate system change it becomes much more difficult to find and fix.

Regards,

Rich

Rich,

I agree. Personally, I attribute it to desktop environments trying to cover every corner case, but causing greater indirection and obfuscation in the long run. Just my two cents, and probably not ammenable to the majority.

Running 1.15 now in all my desktops and the issue seems to be gone ... whatever it was.