OK, ich bin dem Problem auf den Grund gegangen. Letztlich hatte ich mit meiner ersten Vermutung, es liege am Key-repeat, doch recht. Die Mechanismen sind dann aber doch etwas anders.
möglicher Workaround: ersetze die Zeile: keycode 51 = ISO_Group_Shift ISO_Group_Shift ISO_First_Group NoSymbol durch keycode 51 = ISO_Group_Shift ISO_Group_Shift ISO_First_Group NoSymbol NoSymbol NoSymbol ISO_First_Group Das ist aber kein echter Fix, denn nun tritt ein anderes Problem auf: Sobald der Key-repeat einsetzt, kehrt man von der 6. wieder in die 3. Ebene zurück. Wenigstens ist man aber wieder in Ebene 1, wenn die Tasten losgelassen werden. Mit Xmodmap-Mitteln gibt es keinen echten Workaround, weil ein Bug im X-Server vorliegt. Die wirkliche Abhilfe ist, die Skripte installiere_neo und asdf zu benutzen. Die deaktivieren den key-Repeat von allen Modifiern. Oder man macht es selbst per: xset -r 51 Statt setxkbmap lv && xmodmap neo_de.xmodmap also immer: setxkbmap lv && xmodmap neo_de.xmodmap && xset -r 51 Erklärung mit vielen technischen Details für Interessierte: Nur ganz kurz zur Theorie: X unterscheidet Gruppen und Levels. Gruppen (max. 4) sind im Prinzip unabhängige Layouts mit bis zu 256 Levels. Levels entsprechen im Prinzip den Neo-Ebenen. Jede Taste kann für jede Gruppe und jedes Level eine andere Belegung haben. Mit einer xkbmap kann man das auch tatsächlich realisieren. Früher, vor der x keyboard extension, gab es nur genau 2 Gruppen mit genau 2 Levels. Die Xmodmap ist damit kompatibel, und so stehen die ersten zwei Spalten für die 1. Gruppe, die 3. und 4. Spalte für die zweite Gruppe. Danach kommen die restlichen Levels der ersten Gruppe dran, dann die dritte und vierte Gruppe. Die 8 Spalten der Neo-Xmodmap entsprechen also: G1L1, G1L2, G2L1, G2L2, G1L3, G1L4, G3L1, G3L2. Nur, damit das Palaver von Gruppen klarer wird. Mod3r, also die Taste Nr. 51, hat nun (s.o.) in der ersten Gruppe ein Group_Shift stehen, in der zweiten ein First_Group. Das sind aber zwei ganz verschiedene Aktionen: ‣ Group_Shift erhöht die aktuelle Gruppe um 1, ist aber _temporär_ und wird, wenn die Taste losgelassen wird, wieder aufgehoben. ‣ First_Group setzt die Grundeinstellung auf die 1. Gruppe. Keine Aktion beim Loslassen. Diese beiden Dinge – temporäre und grundsätzliche Gruppe – werden aber in zwei verschiedenen Variablen gespeichert! (base_group und locked_group) Seit dem X.org-Server 1.6 werden die key-repeats nur noch per Software direkt im X-Server simuliert. Die xev-Ausgabe ist insofern irreführend, als dass die KeyRelease-Ereignisse gar nicht mehr stattfinden; sie werden nur aus Kompatibilitätsgründen noch vom Server an die Anwendung (z.B. xev) gesendet, haben aber keine direkten Seiteneffekte mehr (z.B. Modifier verändern). Der „virtuelle“ KeyRelease wird dabei unmittelbar beim neuen Repeat-Keypress mit verarbeitet. Der Server merkt sich, dass die Taste gedrückt ist, und macht die entsprechenden Release-Aktionen, wenn die gleiche Taste wiederholt (per Keyrepeat) oder losgelassen wird. Der Ablauf müsste eigentlich so sein: KeyPress: base_group += 1 KeyPress: base_group -= 1, base_group += 1 KeyPress: base_group -= 1, base_group += 1 usw. usf. Dann hätten wir auch kein Problem. Was tatsächlich passiert, ist dies (aufs allerwesentlichste reduziert): KeyPress: groupChange = 1, base_group += groupChange KeyPress: groupChange = -1, groupChange = 1, base_group += groupChange ... D.h. das Rückgängigmachen des vorhergehenden KeyPress wird sofort durch den neuen KeyPress überschrieben. Korrekt wäre folgende 2. Zeile: KeyPress: groupChange -= 1, groupChange += 1, base_group += groupChange Hier liegt also offensichtlich ein Bug im X-Server (xkb/xkbActions.c) vor. Ich denke mal fast, ich bin der erste, der ihn entdeckt hat. Jedenfalls ist er auch noch in der aktuellen Entwicklerversion. Die Gruppen werden nur nicht zyklisch immer weiter erhöht, weil wir in der zweiten (und damit auch vierten) Gruppe ein ISO_First_Group stehen haben. Das erhöht die Gruppe nicht weiter. Am Ende bleibt deshalb die base_group = +1 stehen. Und da kommt man auch nicht raus, wenn man, wie von mir in der letzten Mail vorgeschlagen, ISO_First_Group auf Rollen legt. Denn dadurch kann nur locked_group beeinflusst werden. Ebenso alle anderen keysyms (ISO_Next_Group usw.). Man kommt einfach nicht mehr raus. (Nun ja, ganz richtig ist das auch nicht: Man kann durch verschiedene Reihenfolgen von Mod3 drücken, halten und loslassen die base_group weiter erhöhen, bis man bei 5 ankommt. Die 5. Gruppe ist aber die 1. Gruppe, da es nur vier gibt). Obiger „Fix“ bewirkt, dass das ISO_First_Group schon in der dritten Gruppe steht – damit wird die falsche Zeile gar nicht erst ausgeführt, dafür stattdessen: KeyPress: groupChange -= 1, locked_groups = 1, base_group += groupChange Das ist aber auch nicht richtig, denn jetzt ist die base_group um 1 zu klein. Wir müssen letztlich den key-repeat unbedingt vermeiden und darauf auch im Wiki hinweisen. Einen Bugreport bei freedesktop.org müsste ich wohl auch noch machen. Bin gespannt, ob das unverständliche Gelaber jetzt wirklich einer liest :-). Gruß, Peter