xmodmap weirdness

EdeWolf · 2019-03-15 19:01:53

Hello,

I have a .Xmodmap file, that, when called from a terminal: /usr/bin/xmodmap -verbose ~/.Xmodmap works absolutely flawlessly.
However, when called from .xinitrc or from the windowmanager configuration script, only the first half is read. Unless I call setxkbmap -option before.

# cat .Xmodmap

remove Lock = Caps_Lock
keysym Caps_Lock = Hyper_L
remove mod4 = Hyper_L
clear mod3
add mod3 = Hyper_L

That is, Caps Lock is deactivated and assigned to Hyper_L, but neither is Hyper_L removed from mod4 nor does it get assigned to mod3. Again, calling setxkbmap is not neccessary when .Xmodmap is invoked from a terminal.

What is even more strange, when replacing the call of .Xmodmap by commands, what I would prefer,

xmodmap -e "remove lock = Caps_Lock"
xmodmap -e "keysym Caps_Lock = Hyper_L"
xmodmap -e "remove mod4 = Hyper_L"
xmodmap -e "clear mod3"
xmodmap -e "add mod3 = Hyper_L"

I get the similar results as above, this time additionally the remove from mod4 works, but the clear mod3 does not, and subsequently the follow up add as fails as well, but this time it fails also even if setxkbmap -option has been called beforehand.
And, for above commands in .xinitrc, it seems, "exec xmodmap.." does not work at all, the exec must not be specified. This is strangely enough by itself.

Unfortunately, it seems as if the output from xmodmap also cannot be redirected to a file, as it then won't work at all, nor does it's output appear in the xorg logfile. So I am a bit lost in debugging this.

Can anybody shed some light, please, what is going on here? Or has an idea, how to debug this? In a perfect world I would not use the .Xmodmap, but call the commands from the i3 configuration file.
Specifying it there does not differ from specifying those commands in the .xinitrc.

From Terminal, works as desired:

# /usr/bin/xmodmap -verbose ~/.Xmodmap
! /home/ede/.Xmodmap:
! 1:  remove Lock = Caps_Lock
! Keysym Caps_Lock (0xffe5) corresponds to keycode(s) 0x42
        remove lock =  0x42
! 2:  keysym Caps_Lock = Hyper_L
! Keysym Caps_Lock (0xffe5) corresponds to keycode(s) 0x42
        keycode 0x42 = Hyper_L
! 3:  remove mod4 = Hyper_L
! Keysym Hyper_L (0xffed) corresponds to keycode(s) 0xcf
        remove mod4 =  0xcf
! 4:  clear mod3
        clear mod3
! 5:  add mod3 = Hyper_L
        add mod3 = Hyper_L
!
! executing work queue
!
        remove lock =  0x42
        keycode 0x42 = Hyper_L
        remove mod4 =  0xcf
        clear mod3
        add mod3 = Hyper_L


# xmodmap -pm
xmodmap:  up to 3 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock      
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3        Hyper_L (0x42),  Hyper_L (0xcf)
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

When xmodmap ~/.Xmodmap is called from .xinitrc or i3/config, Step 3 is failing:

# xmodmap -pm
xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Hyper_L (0x42)
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3      
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

When the xmodmap -e "..." commands are called from either .xinitrc or i3/config, step 4 is failing:

xmodmap -pm
xmodmap:  up to 3 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock      
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3      
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

Final note, once the half finished stuff has run during X startup, of course I need to run xsetkbdmap -option, before I can successfully run the xmodmap -e commands or xmodmap ~/.Xmodmap from a terminal.
Again, if I comment out in any of the variants from the startup scripts, a clean X startup so to say I can run the on the terminal without the need for xkbdmap.

But: What has setxkdb to do with all this at all? And why only in startupscripts? And why are the commands in startup scripts only processed partly?

Edit: Added some more italics to hopefully make it more readable

Last edited by EdeWolf (2019-03-15 19:07:53)

seth · 2019-03-15 19:53:11

Post your xinitrc, if there're too many "&"s, that's the cause.
In general, setxkbmap and xmodmap configure the same input device but in different yet overlapping ways.
They *will* collide and you've to maintain thei execution order to get deterministic results.
"exec" replaces the running process (shell script) w/ the one exec'd - one implication is that anyting past the first "exec" call in a script is never processed.

Edit: you do NOT want to make xmodmap the exec command in your xinitrc!

Last edited by seth (2019-03-15 19:54:03)

EdeWolf · 2019-03-16 09:53:39

Thanks very much for hepling again. Your hint brought me one step closer. Nevertheless, moving the xeyes & after the xmodmap makes it work. Well, for most of the time. Unfortunately X seems to behave inconsistently after each reboot. The order however has always been maintained. setxkbdmap always comes first. But again, is only required when xmodmap is invoked via a config file.

However, I then went further and put the xmodmap -e into the windowmanager configuration. And, as long as the setxkbdmap remains in the .xinitrc, it works again for most of the time. But also again not reliably. Placing the setxkbdmap in the i3 config, of course before calling xmodmap -e, makes it fail a 100%.

Now, when it fails, my terminal behaves likes this:

# xmodmap -pm
xmodmap:  up to 3 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Hyper_L (0x42)
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3      
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)


# /usr/bin/xmodmap -e "clear mod3"
# /usr/bin/xmodmap -e "add mod3 = Hyper_L"
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  118 (X_SetModifierMapping)
  Value in failed request:  0x17
  Serial number of failed request:  11
  Current serial number in output stream:  11

Not sure, why the xmodmap -e "add mod3 = Hyper_L is failing here. Calling setxkbmap -option of course I can successfully rerun the whole mapping stack.

Here is my .xinitrc:

#xeyes &
#exec startkde

## Moved to i3 config
#numlockx on

# xmodmap -pm
setxkbmap -option

#/usr/bin/xmodmap -e "remove lock = Caps_Lock"
#/usr/bin/xmodmap -e "keysym Caps_Lock = Hyper_L"
#/usr/bin/xmodmap -e "remove mod4 = Hyper_L"
#/usr/bin/xmodmap -e "clear mod3"
#/usr/bin/xmodmap -e "add mod3 = Hyper_L"

#xmodmap -verbose ~/.Xmodmap

xsetroot -solid "Cadet Blue"

## Moved to i3 config
#feh --bg-scale /data/eyecandy/wallpaper.pic

## Moved to i3 config
#xeyes &

exec i3

Depending on what I am testing, I remove the comments.

seth · 2019-03-16 12:47:51

What's the purpose of "setxkbmap -option" anyway?
Outputs of "setxkbmap -print -query" when things work and when they fail?
Also, do you have any keyboard config in your xorg.conf* ?

EdeWolf · 2019-03-17 20:36:06

What's the purpose of "setxkbmap -option" anyway?

Well, that is exactly what I would like to figure out. All I know, if do NOT specify "setxkbmap -option" in .xinitrc, the xmodmap chain will never be processed completely, no matter wether invoked via ~/.Xmodmap or doing the "xmodmap -e..." sequence.

However, when, after a fresh start of X - without any setxkbmap or xmodmap being called by any config - I run the xmodmap sequence from a terminal, it runs fine, without the need of calling "setxkbmap -opition" before. This behaviour is, what I would like to comprehend.

my 00-keyboard.conf:

Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"       
        Option "XkbLayout" "de"
        Option "XkbModel" "microsoftmult"
        Option "XkbVariant" "nodeadkeys"
EndSection

setxkbmap -print -query when it does not work ("setxkbmap -option" comented out in .xinitrc):

xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwertz)" };
        xkb_types     { include "complete"      };       
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+de(nodeadkeys)+inet(evdev)" };
        xkb_geometry  { include "pc(pc104)"     };               
};
rules:      evdev
model:      microsoftmult
layout:     de          
variant:    nodeadkeys

setxkbmap -print -query when it does work ("setxkbmap -option" active):

xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwertz)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+de(nodeadkeys)+inet(evdev)" };
        xkb_geometry  { include "pc(pc104)"     };
};
rules:      evdev
model:      microsoftmult
layout:     de          
variant:    nodeadkeys

Looks pretty identical. xmodmap -pm may seem slightly more informative in what has not been finished by xmodmap.

Here again the exact .xinitrc I've used for above output. Only difference between working and non working is the pound sign in front of setxkbmap for either run. Here without:

setxkbmap -option
/usr/bin/xmodmap -e "remove lock = Caps_Lock"
/usr/bin/xmodmap -e "keysym Caps_Lock = Hyper_L"
/usr/bin/xmodmap -e "remove mod4 = Hyper_L"
/usr/bin/xmodmap -e "clear mod3"
/usr/bin/xmodmap -e "add mod3 = Hyper_L"
xeyes &
exec i3

seth · 2019-03-17 22:12:56

"setxkbmap -option" unsets all options, but there're none set to begin with.
Did you try whether a noop delay ("sleep 2") has similar impact?

The first part of your modmap dance seems btw. the "caps:hyper" option for xkb.
Also see https://gist.github.com/nh2/ff15f412881f35ab7730 for inspiration.

Arch Linux

#1 2019-03-15 19:01:53

xmodmap weirdness

#2 2019-03-15 19:53:11

Re: xmodmap weirdness

#3 2019-03-16 09:53:39

Re: xmodmap weirdness

#4 2019-03-16 12:47:51

Re: xmodmap weirdness

#5 2019-03-17 20:36:06

Re: xmodmap weirdness

#6 2019-03-17 22:12:56

Re: xmodmap weirdness

Board footer