Dlaczego nie działają?
Zgodnie z artykułem ArchWiki, o którym wspomniałeś:
Serwer X pobiera kody dostępu z urządzenia wejściowego i konwertuje je do
stanu i klucza .
state jest maską bitową modyfikatorów X (Ctrl / Shift / etc).
keysym jest (zgodnie /usr/include/X11/keysymdef.h
) liczbą całkowitą
identyfikować znaki lub funkcje związane z każdym klawiszem (np. poprzez widoczne grawerowanie) układu klawiatury.
Każda postać ma swój własny nadruk keysym, jak plus
, a
, A
, lub
Cyrillic_a
, ale również inne klawisze generują swoje klawsymy, jak
Shift_L
, Left
lub F1
.
Aplikacja w kluczowych wydarzeniach związanych z naciśnięciem / zwolnieniem otrzymuje wszystkie te informacje.
Niektóre aplikacje śledzą takie Control_L
same klucze , inne po prostu szukają bitów modyfikatora w stanie .
Co się stanie, gdy naciśniesz AltGr+ j:
Ty naciskasz AltGr. Aplikacja otrzymuje zdarzenie KeyPressed z kodem <RALT>
klucza 108 ( ) i kluczem 0xfe03 ( ISO_Level3_Shift
), stan to 0.
Naciśnięcie j(który mapuje do „h” w Dvorak bez modyfikatorów). Aplikacja otrzymuje zdarzenie KeyPressed z kodem <AC07>
klucza 44 ( ), kluczem 0xff51 ( Left
) i stanem 0x80 (modyfikator Mod5 jest włączony).
Ty wypuszczasz j. Aplikacja otrzymuje zdarzenie KeyRelease dla klucza
<AC07>
/ Left
o tych samych parametrach.
Następnie zwolnij AltGr- zdarzenie KeyRelease dla AltGr. (Nawiasem mówiąc, stan tutaj wciąż wynosi 0x80, ale to nie ma znaczenia.)
Można to zobaczyć po uruchomieniu xev
narzędzia.
To wszystko oznacza, że chociaż aplikacja otrzymuje taki sam kod Left
klucza ( ) jak z normalnego klucza <LEFT>
, otrzymuje również kod klucza i stan modyfikatora z AltGr. Najprawdopodobniej te programy, które nie działają, obserwują modyfikatory i nie chcą działać, gdy niektóre są aktywne.
Jak sprawić, by działały
Najwyraźniej nie możemy zmienić każdego programu, aby nie szukał modyfikatorów. Wtedy jedyną opcją na wyjście z tej sytuacji jest nie generowanie kluczy i bitów stanu modyfikatorów.
1. Oddzielna grupa
Jedyną metodą, która przychodzi mi do głowy to: definiowanie klawiszy ruchu kursora w oddzielnej grupie i przełącznikiem, z oddzielnym naciśnięciu przycisku, do tej grupy przed naciskając klawisze j, k, l, i( h
,
t
, n
, c
) (grupa zatrzaskowy jest preferowaną metodą na jedną zmianę grupy, jak rozumiem).
Na przykład:
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)" };
};
Teraz, jeśli najpierw naciśniesz, AltGra następnie (osobno) jeden z klawiszy ruchu, to powinno działać.
Jednak nie jest to bardzo przydatne, bardziej odpowiednie byłoby LockGroup
zamiast zatrzasnąć i nacisnąć AltGr przed i po przełączeniu grupy. Jeszcze lepiej może być SetGroup
- wtedy AltGr wybiera tę grupę tylko podczas naciskania, ale to ujawnia aplikacjom klawisz AltGr ( ISO_Group_Shift
/ ISO_Group_Latch
/ cokolwiek zdefiniowano) (ale stan modyfikatora pozostaje czysty).
Ale ... istnieje również możliwość, że aplikacja odczytuje również kody klawiszy (kody prawdziwych kluczy). Wtedy zauważy „fałszywe” klawisze kursora.
2. Nakładka
Bardziej „niskopoziomowym” rozwiązaniem byłaby nakładka (jak
opisano w tym samym artykule ).
Nakładka oznacza po prostu, że jakiś klawisz (prawdziwa klawiatura) zwraca kod innego klawisza. Serwer X zmienia kod klucza klucza i oblicza stan modyfikatora oraz klucz dla tego nowego kodu klucza, więc aplikacja nie powinna zauważyć zmiany.
Ale nakładki są bardzo ograniczone:
- Na serwerze X są tylko 2 bity kontrolne nakładki (tzn. Maksymalnie 2 nakładki).
- Każdy klucz może mieć tylko 1 alternatywny kod.
Co do reszty, implementacja jest dość podobna do metody z osobną grupą:
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
oznacza zmianę bitu kontrolnego podczas naciskania klawisza i przywrócenie go po zwolnieniu klawisza. Powinna być podobna funkcja LatchControls
, ale
xkbcomp
daje mi
Error: Unknown action LatchControls
na kompilacji mapy klawiszy.
(Nawiasem mówiąc, używam również dvorak, a także przypisałem niektóre klawisze ruchów do wysokich poziomów klawiszy alfabetycznych. I natknąłem się również na niektóre zepsute funkcje (wybór w notatkach Xfce i przełączanie pulpitu przez Ctrl-Alt-Lewo / Prawo). Dzięki twoje pytanie i ta odpowiedź, teraz wiem, co to jest nakładka :).)