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

allend · 04-23-2014, 03:28 AM

I am wondering whether these sections from the /usr/bin/startxfce4 script are applicable here.

Code:

if test "x$XDG_CONFIG_HOME" = "x"
then
  BASEDIR="$HOME/.config/xfce4/"
else
  BASEDIR="$XDG_CONFIG_HOME/xfce4"
fi

and then later

Code:

if [ -f $BASEDIR/xinitrc ]; then
  exec $prog $BASEDIR/xinitrc $CLIENTRC $SERVERRC
elif [ -f $HOME/.xfce4/xinitrc ]; then
  mkdir -p $BASEDIR
  cp $HOME/.xfce4/xinitrc $BASEDIR/
  exec $prog $BASEDIR/xinitrc $CLIENTRC $SERVERRC
else
  exec $prog /etc/xdg/xfce4/xinitrc $CLIENTRC $SERVERRC
fi

and from /etc/xdg/xfce4/xinitrc

Code:

# load local modmap
test -r $HOME/.Xmodmap && xmodmap $HOME/.Xmodmap

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.

rshepard · 04-24-2014, 09:27 AM

Quote:

Originally Posted by TobiSGD

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

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

Rich

rshepard · 04-24-2014, 09:41 AM

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

j_v · 04-24-2014, 06:22 PM

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

rshepard · 04-25-2014, 09:40 AM

Quote:

Originally Posted by j_v

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

j_v · 04-25-2014, 06:55 PM

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.

Emerson · 04-27-2014, 12:03 AM

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