summaryrefslogtreecommitdiff
path: root/geometry
diff options
context:
space:
mode:
authorAkihiko Odaki <akihiko.odaki@gmail.com>2022-03-20 23:46:52 +0900
committerSergey Udaltsov <sergey.udaltsov@gmail.com>2022-03-20 23:12:54 +0000
commitfe36f31e8ca1f9022ae5cd2e3058b34b20e7c694 (patch)
treef45d119f1483e4e8c405ec01c436ec7f3fc49301 /geometry
parentf2cc4056caa5db496375eb3fb10e70881d8a64ad (diff)
downloadxkeyboard-config-fe36f31e8ca1f9022ae5cd2e3058b34b20e7c694.tar.gz
Always generate same symbols for Lang1 and Lang2
This change came up after discussions in: https://github.com/google/mozc/issues/552 This change is not complex, but it has somewhat complex background. The following discussion describes it extensively. 1. Six keys somewhat related or unrelated This change involves six keys: ImeOn, ImeOff, Hangul Latin toggle, Hangul to Hanja conversion, Eisu toggle / Caps Lock and Katakana / Hiragana / Romaji. ImeOn is the name used by Microsoft. Apple calls it "Kana switch". ImeOff is the name used by Microsoft. Apple calls it "alphanumeric". Hangul Latin toggle is the name used in keycodes directory. Apple calls it "Hangul/English toggle". Hangul to Hanja conversion is the name used in keycodes directory. Apple calls it "Hanja conversion". ImeOn and Hangul Latin toggle are mapped to Lang1 in USB HID usage and physically located right to space key. ImeOff and Hangul to Hanja conversion are mapped to Lang2 in USB HID usage and physically located left to space key. Eisu toggle / Caps Lock and Katakana / Hiragana / Romaji has key top prints somewhat similar to ImeOff (which says "Eisu") and ImeOn (which says "Kana"), but they have different semantics for Japanese IMEs like macOS Japanese Input Method, Microsoft Japanese IME, and Mozc have two distinct states: IME ON/OFF state and input character type. Eisu_toggle and Hiragana_Katakana are used to toggle the input character type where ImeOn and ImeOff keys are used to IME ON/OFF state. Their physical positions are also different. Eisu toggle / Caps Lock are located where Caps Lock usually sits on a conventional IBM PC keyboard. The position of Hiragana / Katakana / Romaji are described in Microsoft's documentation shown later. The following pages describe the keys listed above: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/keyboard-japan-ime https://developer.apple.com/documentation/uikit/uikeyboardhidusage/uikeyboardhidusagekeyboardlang1 https://developer.apple.com/documentation/uikit/uikeyboardhidusage/uikeyboardhidusagekeyboardlang2 2. Messy situation before this change The following key codes were defined for xfree86: <EISU> = 210; <KANA> = 209; alias <HNGL> = <FK16>; alias <HJCV> = <FK17>; They used to represent ImeOff, ImeOn, Hangul Latin toggle, and Hangul to Hanja conversion, respectively. However, apparently HNGL and HJCV were incorrect. The following commits of xf86-input-keyboard suggest they are actually mapped to 209 and 210: 425c1280439fe37497a33c47b5a8432e59cbfb76 ccf63a61f39e1f107a67c33d6a7ad24ea4c76b7e evdev only has HNGL and HJCV, and they also represent ImeOn and ImeOff, respectively. EISU, KANA, HNGL, HNGL, and HJCV were then used to generate the following symbols respectively: Eisu_toggle, Hiragana_Katakana, Hangul, and Hangul_Hanja. Generating Eisu_toggle for ImeOff and Hiragana_Katakana for ImeOn were semantically incorrect as they rather provide the functionality of Eisu toggle / Caps Lock and Hiragana / Katakana / Romaji. 3. Solution This change solves the situation by always defining HNGL and HJCV key codes and generating Hangul for Lang1 keys and Hangul_Hanja for Lang2 keys. In this way, Japanese and Korean IMEs can know keys they need to toggle IME states. Japanese IMEs can also distinguish ImeOn and ImeOff from Eisu toggle / Caps Lock and Hiragana Katakana / Romaji. This change lets Hangul and Hangul_Hanja symbols overload semantics of Japanese and Korean IMEs. This is based on the following rationales: * evdev always emitted Hangul and Hangul_Hanja symbols before this change and therefore it would be least disruptive. * The key pairs are physically located in the same positions so users would expect them to perform interchangeably when switching Japanese and Korean IMEs. * Distinguishing from key codes is not possible anyway because the underlying hardware complies USB HID Usage Table, which do not distinguish those keys.
Diffstat (limited to 'geometry')
-rw-r--r--geometry/macintosh8
1 files changed, 4 insertions, 4 deletions
diff --git a/geometry/macintosh b/geometry/macintosh
index d7971ff..172646a 100644
--- a/geometry/macintosh
+++ b/geometry/macintosh
@@ -1203,7 +1203,7 @@ xkb_geometry "applealu_jis" {
corner= 1,
{ [ 29.5, 15 ] }
};
- shape "EISU" {
+ shape "HNGL" {
corner= 1,
{ [ 20, 18 ] }
};
@@ -1223,7 +1223,7 @@ xkb_geometry "applealu_jis" {
corner= 1,
{ [ 29.5, 15 ] }
};
- shape "KANA" {
+ shape "HJCV" {
corner= 1,
{ [ 20, 18 ] }
};
@@ -1335,8 +1335,8 @@ xkb_geometry "applealu_jis" {
left= 0;
keys {
{ <LALT>, "LALT", 0 }, { <LMTA>, "LMTA", 3.5 },
- { <EISU>, "EISU", 3.5 }, { <SPCE>, "SPCE", 3.5 },
- { <KANA>, "KANA", 3.5 }, { <RMTA>, "RMTA", 3.5 },
+ { <HNGL>, "HNGL", 3.5 }, { <SPCE>, "SPCE", 3.5 },
+ { <HJCV>, "HJCV", 3.5 }, { <RMTA>, "RMTA", 3.5 },
{ <RALT>, "RALT", 3.5 }, { <CAPS>, "CAPS", 3.5 }
};
};