Warum funktionieren sie nicht?
Laut dem von Ihnen erwähnten Artikel im ArchWiki :
Der X-Server erhält Schlüsselcodes vom Eingabegerät und konvertiert sie in den
Status und das Keysym .
state ist die Bitmaske der X-Modifikatoren (Strg / Umschalt / etc).
Keysym ist (nach /usr/include/X11/keysymdef.h) der ganzen Zahl, die
Identifizieren von Zeichen oder Funktionen, die jeder Taste zugeordnet sind (z. B. über die sichtbare Gravur) eines Tastaturlayouts.
Jedes druckbare Zeichen hat seine eigene keysym, wie plus, a, Aoder
Cyrillic_a, aber auch andere Schlüssel erzeugen auch ihre Keysyms, wie
Shift_L, Leftoder F1.
Die Anwendung in den wichtigsten Presse- / Release-Ereignissen erhält alle diese Informationen.
Einige Anwendungen verfolgen Keysyms wie Control_Lvon selbst, andere suchen nur nach den Modifikatorbits im Status .
Was passiert also, wenn Sie AltGr+ drücken j:
Sie drücken AltGr. Die Anwendung erhält das KeyPressed-Ereignis mit dem Schlüsselcode 108 ( <RALT>) und dem Keysym 0xfe03 ( ISO_Level3_Shift). Der Status ist 0.
Sie drücken j(was in dvorak ohne Modifikatoren „h“ zugeordnet ist). Die Anwendung erhält das KeyPressed-Ereignis mit dem Schlüsselcode 44 ( <AC07>), dem Keysym 0xff51 ( Left) und dem Status 0x80 (Modifikator Mod5 ist aktiviert).
Sie freigeben j. Die Anwendung erhält das KeyRelease-Ereignis für den Schlüssel
<AC07>/ Leftmit denselben Parametern.
Dann Release AltGr- KeyRelease-Ereignis für AltGr. (Übrigens ist der Zustand hier immer noch 0x80, aber das spielt keine Rolle.)
Dies wird angezeigt, wenn Sie das xevDienstprogramm ausführen .
Das alles bedeutet also, dass die Anwendung zwar denselben Keysym-Code ( Left) wie der normale Schlüssel <LEFT>erhält, aber auch den Keysym-Code und den Modifikatorstatus von AltGr. Höchstwahrscheinlich beobachten Programme, die nicht funktionieren, die Modifikatoren und möchten nicht funktionieren, wenn einige aktiv sind.
Wie man sie zum Laufen bringt
Anscheinend können wir nicht jedes Programm so ändern, dass es nicht nach Modifikatoren sucht. Die einzige Möglichkeit, dieser Situation zu entkommen, besteht darin, keine Schlüsselsymbole und Statusbits der Modifikatoren zu generieren.
1. Separate Gruppe
Die einzige Methode, die mir einfällt , ist: Cursor - Bewegungstasten in einer separaten Gruppe und Schalter, mit einer separaten Taste drücken, um die Gruppe zu definieren , bevor die Schlüssel zu drücken j, k, l, i( h,
t, n, c) (Gruppe Rast ist die bevorzugte Methode für einen einmaligen Gruppenwechsel, wie ich verstehe).
Beispielsweise:
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compatibility {
include "complete"
interpret ISO_Group_Latch { action = LatchGroup(group=2); };
};
xkb_symbols {
include "pc+us(dvorak)+inet(evdev)"
key <RALT> { [ ISO_Group_Latch ] };
key <AC07> {
type[Group2] = "ONE_LEVEL",
symbols[Group2] = [ Left ]
};
key <AC08> {
type[Group2] = "ONE_LEVEL",
symbols[Group2] = [ Down ]
};
key <AC09> {
type[Group2] = "ONE_LEVEL",
symbols[Group2] = [ Right ]
};
key <AD08> {
type[Group2] = "ONE_LEVEL",
symbols[Group2] = [ Up ]
};
};
xkb_geometry { include "pc(pc104)" };
};
Wenn Sie jetzt zuerst AltGrund dann (separat) eine der Bewegungstasten drücken , sollte dies funktionieren.
Dies ist jedoch nicht sehr nützlich. Besser wäre es, LockGroup
vor und nach dem Gruppenwechsel anstelle von Latch AltGr zu drücken und zu drücken. Auch kann besser sein, SetGroup- dann AltGr diese Gruppe wählen würde nur während gedrückt wird, aber das ist bekannt , auf die Anwendungen AltGr des keysym ( ISO_Group_Shift/ ISO_Group_Latch/ was auch immer definiert ist) (aber Modifikator Zustand bleibt sauber).
Aber ... es besteht auch die Möglichkeit, dass die Anwendung auch Schlüsselcodes (die Codes der realen Schlüssel) liest. Dann werden die "falschen" Cursortasten bemerkt.
2. Überlagerung
Die "Low-Level" -Lösung wäre das Overlay (wie im selben Artikel
beschrieben).
Überlagerung bedeutet einfach, dass eine (echte Tastatur-) Taste den Schlüsselcode einer anderen Taste zurückgibt. Der X-Server ändert den Schlüsselcode eines Schlüssels und berechnet den Modifikatorstatus und das Schlüsselsymbol für diesen neuen Schlüsselcode, sodass die Anwendung die Änderung nicht bemerken sollte.
Überlagerungen sind jedoch sehr begrenzt:
- Es gibt nur 2 Overlay-Steuerbits im X-Server (dh es können maximal 2 Overlays vorhanden sein).
- Jeder Schlüssel kann nur einen alternativen Schlüsselcode haben.
Im Übrigen ähnelt die Implementierung der Methode mit einer separaten Gruppe:
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compatibility {
include "complete"
interpret Overlay1_Enable {
action = SetControls(controls=overlay1);
};
};
xkb_symbols {
include "pc+us(dvorak)+inet(evdev)"
key <RALT> {
type[Group1] = "ONE_LEVEL",
symbols[Group1] = [ Overlay1_Enable ]
};
key <AC07> { overlay1 = <LEFT> };
key <AC08> { overlay1 = <DOWN> };
key <AC09> { overlay1 = <RGHT> };
key <AD08> { overlay1 = <UP> };
};
xkb_geometry { include "pc(pc104)" };
};
SetControlsbedeutet, das Steuerbit zu ändern, während die Taste gedrückt wird, und es bei der Tastenfreigabe wiederherzustellen. Es sollte eine ähnliche Funktion geben LatchControls,
xkbcompgibt mir aber
Error: Unknown action LatchControls
auf Keymap-Kompilierung.
(Übrigens verwende ich auch dvorak und habe einige Bewegungstasten auf hohe Ebenen alphabetischer Tasten neu zugeordnet. Außerdem bin ich auf einige Funktionsstörungen gestoßen (Auswahl in Xfce-Notizen und Desktop-Schalter durch Strg-Alt-Links / Rechts). Dank deine Frage und diese Antwort, jetzt weiß ich was ein Overlay ist :).)