Re: [Neo] [ticket] #178: [xkbmap] Tastenkombinationen mit 4./7. Ebene bei KDE-Programmen

[Neo-Layout]

#178: [xkbmap] Tastenkombinationen mit 4./7. Ebene bei KDE-Programmen
-+--
 Reporter:  martin_r |   Owner: 
 Type:  Fehler/Defekt|  Status:  new
 Priority:  hoch |   Milestone:  Neo Version 2.0
Component:  Treiber: Linux – Xkbmap  | Version:  2.0 BETA   
 Keywords:   |  
-+--

Comment(by petere):

 Bestätigt. KDE interpretiert offenbar z.B. Strg+Mod4+i gleichzeitig als
 Strg+i und bemerkt einen Konflikt.

-- 
Ticket URL: 
Neo-Layout 
Das Neo-Tastaturlayout ist ein freies und ergonomisch optimiertes 
Tastaturlayout für die deutsche Sprache, das auch sehr viele Sonderzeichen 
direkt verfügbar macht.

Re: [Neo] [ticket] #175: Bestimmte Tasten der Erstbelegung werden an die folgenden vererbt.

[Neo-Layout]

#175: Bestimmte Tasten der Erstbelegung werden an die folgenden vererbt.
--+-
  Reporter:  stephan  |   Owner:  
  Type:  Aufgabe/TODO |  Status:  closed  
  Priority:  niedrig  |   Milestone:  
 Component:  Treiber: Linux – Xkbmap  | Version:  2.0 BETA
Resolution:  fixed|Keywords:  
--+-
Changes (by petere):

  * status:  reopened => closed
  * resolution:  => fixed


Comment:

 erledigt:
 wiki:"Neo unter Linux einrichten/xkbmap#ZwischenzweiLayoutsumschalten"

-- 
Ticket URL: 
Neo-Layout 
Das Neo-Tastaturlayout ist ein freies und ergonomisch optimiertes 
Tastaturlayout für die deutsche Sprache, das auch sehr viele Sonderzeichen 
direkt verfügbar macht.

Re: [Neo] [neo_de.xmodmap] Manchmal Ebene-3-Lock nach Benutzung der 6. Ebene.

[Peter Eberhard]

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 u