Warum arbeiten sie nicht?
Gemäß dem Artikel von ArchWiki, den Sie erwähnt haben:
Der X-Server erhält die Schlüsselcodes vom Eingabegerät und konvertiert sie in den Zustand und das Schlüsselwort .
state ist die Bitmaske der X-Modifikatoren (Ctrl / Shift / etc).
keysym ist (entsprechend
/usr/include/X11/keysymdef.h
) die ganze ZahlZeichen oder Funktionen identifizieren, die jeder Taste zugeordnet sind (z. B. über die sichtbare Gravur) eines Tastaturlayouts.
Jedes druckbare Zeichen hat seine eigene keysym, wie
plus
,a
,A
oderCyrillic_a
aber andere Tasten auch ihre Keysyms erzeugen, wieShift_L
,Left
oderF1
.
Die Anwendung in den Tastendruck- / Veröffentlichungsereignissen erhält alle diese Informationen.
Einige Anwendungen verfolgen Keysyms wie
Control_L
von 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 keysym 0xfe03 (ISO_Level3_Shift
). Der Status ist 0.Sie drücken j(was in dvorak ohne Modifikatoren auf "h" kartiert). Die Anwendung erhält ein KeyPressed-Ereignis mit dem Schlüsselcode 44 (
<AC07>
), keysym 0xff51 (Left
) und dem Status 0x80 (Modifier Mod5 ist aktiviert).Sie lassen los j. Die Anwendung erhält das KeyRelease-Ereignis für den Schlüssel
<AC07>
/Left
mit den gleichen Parametern.Dann geben Sie das AltGrKeyRelease-Ereignis für AltGr frei. (Übrigens ist der Zustand hier immer noch 0x80, aber das spielt keine Rolle.)
Dies ist sichtbar, wenn Sie das xev
Dienstprogramm ausführen .
Das bedeutet also, dass die Anwendung zwar den gleichen keysym-Code ( Left
) erhält wie der normale Schlüssel <LEFT>
, aber auch den keysym-Code und den Status des Modifizierers von der AltGr. Höchstwahrscheinlich beobachten die Programme, die nicht funktionieren, die Modifikatoren und möchten nicht funktionieren, wenn einige aktiv sind.
Wie können sie funktionieren?
Anscheinend können wir nicht jedes Programm ändern, um nicht nach Modifikatoren zu suchen. Die einzige Möglichkeit, dieser Situation zu entgehen, besteht darin, die Keysyms und Statusbits der Modifikatoren nicht zu erzeugen.
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 den Tasten vor definieren j, k, l, i( h
, t
, n
, c
) (Gruppe Verrastung ist die bevorzugte Methode für eine Zeit Gruppenwechsel, wie ich es verstehe).
Zum Beispiel:
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. Es wäre sinnvoller, LockGroup
anstelle von Latch und AltGr vor und nach dem Gruppenwechsel zu drücken. Vielleicht noch besser SetGroup
- dann würde AltGr diese Gruppe nur auswählen, wenn sie gedrückt wird, aber dies zeigt den Anwendungen AltGrs keysym ( ISO_Group_Shift
/ ISO_Group_Latch
/ was auch immer definiert ist) (aber der Status des Modifizierers bleibt sauber).
Es gibt aber auch die Möglichkeit, dass die Anwendung auch Keycodes (die Codes der echten Schlüssel) liest. Dann werden die "falschen" Cursortasten angezeigt.
2. Überlagerung
Die eher "Low-Level" -Lösung wäre die Überlagerung (wie im selben Artikel beschrieben).
Überlagerung bedeutet einfach, dass einige Tasten (echte Tastatur) den Keycode einer anderen Taste zurückgeben. Der X-Server ändert den Schlüsselcode eines Schlüssels und berechnet den Status des Modifizierers und das Schlüsselsymbol für diesen neuen Schlüsselcode, sodass die Anwendung die Änderung nicht bemerken sollte.
Overlays 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 ist die Implementierung der Methode mit einer separaten Gruppe sehr ähnlich:
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)" }; };
SetControls
bedeutet, das Steuerbit bei gedrückter Taste zu ändern und bei der Tastenfreigabe wieder herzustellen. Es sollte eine ähnliche Funktion geben LatchControls
, xkbcomp
gibt mir aber
Error: Unknown action LatchControls
auf der Keymap-Kompilierung.
(Übrigens benutze ich auch Dvorak und habe einige Bewegungs-Keysymptome auf hohe alphabetische Tastenbelegungen umgestellt. Außerdem sind einige fehlerhafte Funktionen aufgetreten (Auswahl in Xfce-Notizen und Desktop-Schalter durch Strg-Alt-Links / Rechts) deine Frage und diese Antwort, jetzt weiß ich, was eine Überlagerung ist :).)