Xmodmap problems and inconsistencies with more than 4 alternative symbols per key

bugsxmodmapxorg

I was trying to make my keyboard more useful and used xmodmap to map mathematical and greek symbols to mod3 modifier level. Where caps lock is mapped to mod3. As I understand, the 8-entry lines in .Xmodmap work as following:

[nothing], [shift], [mod3], [mod3+shift], [altgr], [altgr+shift], [altgr+mod3], [altgr+shift+mod3]

I used this and it mostly worked. Except for some strange occurences. For instance:

keycode  49 = backslash bar includes includedin infinity infinity EuroSign EuroSign

This produces the first four entries nicely, but then it cycles around (altgr+key=backshlash, not infinity). However, if I do

keycode  10 = backslash bar includes includedin infinity infinity EuroSign EuroSign

it produces first four entries and infinities, but the euro sign doesn't show (I get includes and includedin instead). Notice that I just used a different key, everything else is the same! Even with only 6 entries (in case there was a parsing problem with 8), infinities are not shown on that particular key.

Furthermore, I mapped greek letters to 3rd and 4th entries (mod3 and mod3+shift). The lowercase work fine, but the uppercase doesn't work for Shift+mod3+S and Shift+mod3+W and Shift+mod3+X. It's not a font problem, xev doesn't show any event when I use these combinations.

The entry is

keycode  39 = s S Greek_sigma   Greek_SIGMA   integral integral downarrow downarrow

Additionally, the last two entries mostly don't work.

Even worse, one line gets particularly confused. I entered

keycode  51 = zcaron Zcaron zcaron Zcaron dstroke Dstroke dstroke Dstroke

but when I do xmodmap -pke I get

keycode  51 = zcaron Zcaron zcaron Zcaron dstroke Dstroke dstroke Dstroke zcaron Zcaron dstroke Dstroke zcaron Zcaron dstroke Dstroke

Notice it duplicated all the entries. A couple of keys do that, but not all of them!

So, my questions are:

  • Am I using the 8-entry lines correctly?
  • Why do I get different number of working keysyms on different keycodes?
  • Is it possible that something in the window manager maps these combinations and swallows them?
  • Why are some lines getting duplicated when they are applied?
  • Is this an obscure xlib bug?
  • Is the modifier functionality limited?

Note that I'm in a unique situation where there simply can't be any unknown shortcuts that I don't know about because my window manager is of my own making and I control all of them.

More details: the mapping of caps lock is done like this:

keycode  66 = Mode_switch

clear lock
clear control
clear mod1
clear mod2
clear mod3
clear mod4
clear mod5
add control = Control_L Control_R
add mod1 = Alt_L Meta_L
add mod2 = Num_Lock
add mod3 = Mode_switch
add mod4 = Super_L Super_R Hyper_L
add mod5 = ISO_Level3_Shift

The system is a freshly updated arch linux.

Edit: I found out that a small part of the problem (the SWX that didn't work at all) was due to the adjacency of the keys on the keyboard (key jamming, couldn't handle 3 concurrently pressed keys in this combination). Right shift removed the problem for W and X but not for S (on this particular keyboard).

The rest is still a mystery, particularly the broken 5th and 6th entry for keycode 49 (the totally useless thingy above the tab).

Best Answer

I'd better answer my own question for future reference.

After a bit of in-depth research, I found out that xmodmap is actually deprecated and is roughly patched over the xkb keyboard model. The xkb model doesn't use a linear array of alternatives, but splits layouts into groups, with each group having a couple of characters in different shift levels. The xmodmap definitions fill the entries in a very funny order: group 1, level 1,2, group 2, level 1,2, group 1, levels 3.... The groups are meant to be like "layouts" and aren't usually accessed with modifiers but with toggling. The exception is the Mode_switch character that I used, but it only accesses group 2.

That would all be fine, except keys have types. Every key is defined by the layout to be TWO_LEVEL, FOUR_LEVEL, FOUR_LEVEL_ALPHANUMERIC and so on, and each level can have different notion of which modifiers map to which levels. The behaviour I assumed (8 levels, all combinations) was actually LOCAL_EIGHT_LEVEL that wasn't used at all by the layout. So in the case of keycode 51, the default was actually TWO_LEVEL, and xmodmap filled 3 groups with the 6 keys instead of adding 6 levels to 1st group. The 3rd group wasn't reached by the Mode_switch modifier. Using another key resulted in different behaviour because pre-defined type was different.

As with the repetitions in the printout by xmodmap, I'm not sure exactly what happens (I printed the xkb definitions and all was fine), but I'm not surprised that errors occur when you map from a variable-length multidimensional array to a single list of symcodes. The output doesn't reflect the actual state anyway.

In conclusion, xmodmap is evil. Don't ever use it. Its behaviour is erratic and ill-defined at best. It doesn't do what it says it does. Make your own xkb maps. Reuse most of the layout by include-ing and add modifications that you need.

In my case, the solution is to derive the second group from greek layout and substitute math symbols in strategic places, plus some modification in the first group.

Most cheap keyboards are very limited when it comes to pressing 3 keys at a time. That resulted in erratic and hardware-dependent failures for some keys. I'll experiment around with different modifier keys (the most useless key in the world - the menu key, or similarly useless right win-key), and possibly buy a better keyboard. Combination of both problems (broken-by-design hardware + evil deceptive software) created a confusing random-looking situation that at first prevented me to see them as separate problems.

Reading material:

Related Question