【注意】
本記事ではところどころ、

バックスラッシュ（本来は半角 \, U+005C, REVERSE SOLIDUS）を 全角＼ (U+FF3C, FULLWIDTH REVERSE SOLIDUS) で。
円記号（本来は半角 ¥, U+00A5, YEN SIGN) を 全角￥ (U+FFE5, FULLWIDTH YEN SIGN) で書き記しています。

これは使用しているフォントによって、この 2 つの半角文字が混同され、表示上区別がつかない場合があるためです。（日本語環境による。 Windows や Webブラウザのフォントなど）
便宜上、そのようにしていますが、本来は全て 半角ですのでご注意ください！

🔶 概要

ふと、Linux Mint Cinnamon エディション¹ で、
　　[システム設定] ＞ [キーボード] ＞ [レイアウト]
画面を開き、"日本語(OADG 109A)" レイアウトを表示させてみた。
しかし、これが おかしな事 に気づいた。

一般的な 109A 日本語キーボード (フルサイズ・キーボード) は以下のようになっているはずだ。

　出典: 109日本語キーボード | 森山将之さんHP

違いを列挙すると、

  1. 右上の角 { ¥ | ー } キーが無い！
  2. 右下の角 { \ _ ろ } キーが無い！
  3. 左下の角 { > < | ¦ } という見知らぬキーが有る
  4. スペースの左右に有るはずの { 無変換, 変換, カタカナ/ひらがな } キーが無い！

となる。

あと 1, 2, 4 が無いせいで BackSpace と右 Shift, Space キーがやたらとデカイ。他に、かな入力での "ひらがな" 表記も無いし、 Meta やら Super やらの UNIX 的な表記であったりと違いがあったりするのだが… まあ、それはいいや。本質的な問題ではないから。

とにかく、
キーの配列レイアウトが真実と異なっている のだ。なぜなのだろうか？
このページでは、この謎を追う。

🔶 でもちゃんと入力できるよ？困ることあるの？

そう。このキーボード・レイアウトが別にどうであろうが、日本語キーボードからの入力は一切問題が無いように思える。"日本語キーボード" や "OADG109A 日本語キーボード" レイアウトを選択していて Fcitx などの IME を導入して正しく設定していればちゃんとキー入力ができる。

レイアウト図には無いキーも問題なく入力されるし、増えた謎のキーは、そもそもないので入力できないが問題はない。{ < > | } とかは別のキー＋ Shiftキーの組み合わせであるので使うこと無いし、 ¦ については入力したいとも思わない。
むしろ、 「え！？そんなんあったの！？」 みたいな。

…では問題はないのか？

$\huge{いいや。ある。}$

それは オンスクリーン・キーボード（a.k.a. OSK, スクリーンキーボード, 仮想キーボード, ソフトウェア・キーボード）を使うときだ。
オンスクリーン・キーボードとは、画面上に表示されるキーボードで、クリックすることで文字を入力できるというもの。²

　$\tiny{※\ Androidスマホでの例:\ Hackers\ Keyboard}$

これのレイアウトが、実は上記のおかしなレイアウトを元にしてしまっているのだ。
俺ちゃんの場合、具体的には Linux Mint のデフォルトのオンスクリーン・キーボードである Onboard に支障が出ていた。

　$\tiny{※ Linux\ Mint\ の例：オンスクリーン・キーボード\ Onboard}$

つまり、
この状態だと、 ¥ や | や _ や \ などのいくつかの文字が入力できない。これは特に Linux 使いの真骨頂である 端末を操作する時に非常に困る。

そこで筆者は問題を＊ちゃんと＊調べ始めた。³

【注意】レイアウトを修正すれば Onboard もすぐ直るわけではない

-- 🖱️ クリックで開く --

ただし、これは "参考にして作られてしまっている" というだけ。Onboard が動的にこのレイアウト（ジオメトリ情報という）を参照して配列を構成しているわけではないので、例えジオメトリの方を正しく直したとしても即座に Onboard のレイアウトが訂正されるわけではない。別途 Onboard 側でレイアウトを正しく定義してやる必要があるのだ。

ようするに、ジオメトリ情報は主に 設定画面での確認用・参考用 であって、これを修正することによる即効性はない。…ただし、全く関係がないかと言うとそれも違う。

以降で詳しく述べるが X-WindowSystem において、これらを実装しているのは XKB という仕組みになる。実は Onboard も押された キーの正当性検査にこの XKB を利用 しており、モデル等の情報が異なっていると "￥" や "無変換" といった日本語特有のキーの定義が見つからないため「無効」と判断されてしまうことがある。
特に pc104 や pc105 のようなキーボードに誤って設定⁴ されていると、
$\tiny{(たまにそう設定するよう安易に勧めているページを見かけるが…\ Oops!)}$
キーを押すたびに正当性検査が失敗して、それらのレイアウトにフォールバックされるようだ。結果、日本語特有のキーは動作しなくなってしまう。

🔶 規格としてはどっちが正しいの？

🔵 そもそも OADG って何よ？

"OADG109A 日本語キーボード" は名前の通り、 PC オープン・アーキテクチャー推進協議会（The PC Open Architecture Developers Group） が策定した日本語のキーボードにおける標準仕様である。
この OADG とは 1991 年に PC 製品を販売しているメーカー各社により作られた連合団体。 PC/AT互換機の共通仕様を決め、普及を目指した。

✍️ 歴史的経緯を踏まえた詳細:

-- 🖱️ クリックで開く --

OADG 創設前。例によって、それまで各社バラバラに日本語キーボードのレイアウトを決めていたが、それだとソフトウェア側も多種多様なレイアウトに対応せねばならず、欧米とも互換性がなく、不便だった。「この機種だとあのキーはない」、「この機種では Shift と同時押しじゃないと駄目」とかいちいち各社・各製品ごとに対応を考慮せねばならないからだ。

そこで IBM が自社の DOS/V を売るため PC/AT 互換機の普及を図ったのを期に、日本のメーカー各社が協力して統一した標準規格として定めることにしたのが、この OADG の仕事である。当時の国産 PC 市場の支配者だった NEC を除く、各社が参画した。ちょうど都合よく、 Windows 95 の爆発的な普及もあってこの試みは成功した。NEC の独壇場だった国内 PC の牙城は崩れ、 PC/AT 互換機の時代が訪れた。規格統一や標準化がひどく苦手な日本においては珍しく成功した例と言えよう。…まあきっかけは IBM のお陰なのだが。

前身としては "OADG 106 日本語キーボード" を元にしており、これを一部拡張させたり、一部刻印を消去したりして生まれたのがこの "OADG 109A 日本語キーボード" だ。この成果は "JIS X4064" として JIS 規格にも認められ、主要なキーボードの例として採用された。 (2002 - 2003)

　　【参考】ＯＡＤＧ１０９Ａキーボード　ＪＩＳによる参照キーボードに！

OADG は NEC PC-98 シリーズの市場独占の終焉、および PC/AT互換機の普及とともに役割を終え、 2004 年に解散した。が、その成果物は今日も標準として利用されている。

なお、 109A の後継には "112 日本語キーボード" というものもある。

　　【参考】キー配列 - Wikipedia

🔵 でも OADG なんて言わないよね？ JISキーボードって言うよ？

その通り。
よく日本語キーボードは国内では "JIS配列" とか "JISキーボード" と呼ばれることが多く、そちらのほうが浸透しているように思われる。各社製品にもそのように記載されている。

それはおそらく JIS(旧：日本工業規格、新：日本産業規格) の方が古くから存在し、国内ではネームバリューがあり、キーボードに限らない包括的な工業製品全般の規格としてよく周知されているからだろう。

ただし、
JIS X 6002 がこれの元となった規格なのだが、1980年公布と非常に古く、 SOT などの現代では使われなくなったキーも多く、現状とはかけ離れた仕様であると言える。（それでも、 ASCII文字キーやかな文字キーについては現在とほぼ同じではあるのだが… ⁵)
このため、客観的に見て、現在のキーボードが "JISキーボード" などと呼ばれるのはかなり違和感がある。

対して、
OADG 109A は PC/AT互換機仕様に特化したピンポイントでの標準仕様であり、現代に即したキー配列が仕様でがっちり定められており、 IBM の後ろ盾もあって PC の統一規格として世界的に認められたものだ。Linux でこちらの方が使用されるのも妥当と思える。

🔵 OADG はわかった。で？仕様上はどっちが正しいの？

仕様を策定するだけしておいて、なぜか 完全準拠していない、 独自仕様・拡張がその後も続いている という気色悪い事態が日本ではよくある。
$\tiny{本当に淘汰・統一が苦手な民族だと苦笑する。}$

だから筆者は "OADG 109A 日本語キーボード" についてもそうなのではないかと疑った。しかし、これについては正しいようだ。

本記事の冒頭に示した "109A 日本語キーボード" 画像の配列は正しく、 Linux のレイアウト図に表示された配列の方が間違っている。 OADG の仕様書は解散して久しいので公式では失われてしまっているのだが、 "The Ineternet Archive" の "Wayback Machine" が保存してくれている魚拓ページから、辿ることで参照が可能だ。

また、
個人ではあるが次のページでも考察・解説されており、参考になる。

【参考】JIS配列キーボードとOADG配列キーボード | コグノスケ

では、
　　なぜ Linux 側は仕様を守っていないのか？

どうやらこれは pc105 多国語キーボード配列を元にしているためのようだ。

📝 MEMO: pc105 キーボードとは？:

-- 🖱️ クリックで開く --

デスクトップ PC 向けのキーボード配列の一つで、主に欧州各国の主要言語で問題なく必要な文字種が打てるように考案されたキー配列であり、（米国や日本を含めたアジアを除くが）多くの国で採用されている型式のキーボード。国際規格である ISO と IEC( 国際電気標準会議) 規格で定められている。(ISO/IEC 9995)

欧州各国でキー表面の刻印は異なり、違う文字種が打てるが、レイアウト自体は同じ形状をしており、設定などを変えることで各キーの機能とのマッピングを変更可能。つまり欧州各国で共通して利用できる。（刻印さえ気にしなければ。別の国用の刻印がオプションで売られているものもある⁶）

なお、蛇足だが、
これらはアメリカ合衆国の所謂 US配列キーボード とは異なる。US配列(または ASCIIキーボード, ANSI キーボード) は 101 が基本で 104 が Win キーなどが拡張 されたキーボードだ。同様に、多国語キーボード 105 は 102 の拡張。 日本語キーボード 109 は 106 の拡張 である。109A は更にそれを刻印を削るなどしてマイナー・チェンジしたものだ。

【参考】キー配列 - Wikipedia

Linux では（例えば setxkbmap コマンドなど XKB のモデル指定で）キーボードの指定が明示的に行われていない場合、需要の大きさ的にこの pc105 が仮定されるらしいのだ。そして、こちらが肝なのだが、レイアウト情報もこの pc105 を元にして表現する。

例え OADG109A や jp106 などのキー配列を指定したとしても、それは pc105 レイアウトからのちょっとしたキー内容の変更 のように扱われ、キー全体の配置レイアウト（ジオメトリ情報という）についてはそのまま pc105 のものが用いられてしまっているのだ。

Linux「あ？ OADG 109A だって？どうせ pc105 の亜種だろ？
　　　　刻印とキーの機能の紐付けだけ、違ってるやつだろ？」

って 誤認識されてる みたいな感じ。
実際はジオメトリも結構違うんですけど。。。。
十把一絡げに、一緒くたにされている。

【参考】PC and VT100 Keyboard Layouts Compared - RedGrittyBrick

📝 MEMO:
主なキーボードレイアウトの違いを絵で確認できるサイト。コンパクト型のキーボードや歴史的なキーボードについても触れられており、興味深い。

🔶 OADG準拠の正しいレイアウトに変更する

…さて、
前置きが長くなってしまったが。
本題に取りかかろう。

レイアウトを修正する。

🔵 XKB のファイルを確認して正しいレイアウトを再現できるモデルを探す

XKB のファイルは /usr/share/X11/xkb/ ディレクトリ以下にある。
そのうち、 OADG109A の定義は以下のファイルにある。
less で表示させているが、長いので要点部分以外は省略する。

	$ less /usr/share/X11/xkb/symbols/jp
	-- (snip) --
	partial alphanumeric_keys
	xkb_symbols "OADG109A" {

		include "jp(common)"

		name[Group1]= "Japanese (OADG 109A)";

		key <AE10>  {[ 0            ]};
		key <AE13>  {[ yen, bar     ]};
	};
	// Keys that are common to 106-key and 109-key keyboards.
	hidden partial alphanumeric_keys
	xkb_symbols "common" {

		key <HZTG>  {[ Zenkaku_Hankaku, Kanji ], type[group1]="PC_ALT_LEVEL2" };
	-- (snip) --
	key <AB11>  {[ backslash, underscore ]};

		key <NFER>  {[ Muhenkan ]};
		key <XFER>  {[ Henkan, Mode_switch ], type[group1]="PC_ALT_LEVEL2" };
		key <HKTG>  {[ Hiragana_Katakana, Romaji ], type[group1]="PC_ALT_LEVEL2" };

		key <PRSC>  {[ Print, Execute ], type[group1]="PC_ALT_LEVEL2" };
	};

ここでは { 全角/半角, 変換, 無変換, かな/カナ } などの日本語独特のキーが定義されている。特に重要なのは、以下の2つのキー定義だ。

key <AE13> : ¥ （エンサイン）キー。 Shift を押したときは | （バーティカル・バー）。
key <AB11> : \ （バックスラッシュ）キー。Shift を押したときは _ （アンダー・スコア）。

これをよく覚えておこう。

📝 MEMO: <AE13> とか <AB11> って何さ？:

-- 🖱️ クリックで開く --

<AE13> のような表記は見慣れない形式だが、これは evdev の スキャンコード。

evdev はキーボードなどの入力を処理するドライバで、物理キーボードのキーを押すと、まずこのスキャンコードとして読み取る。（例： \ キー → <AB11> ）次にそれを /usr/share/X11/xkb/keycodes/evdev で定義されているマッピングを用いて XFree86 という古い X-Windows System の形式であるキーコードへと変換する。（例： <AB11> → 97 ）
また、
スキャンコードは上述の symbols ディレクトリにあるファイルを参照してキーがもたらす機能性を定義した keysym として解釈される。（例： <AB11> → backslash ）最終的に、それを受け取った Xサーバーやウィンドウマネージャー、アプリケーションによって効果が判断され、実行される。

🔹xev コマンドで＼を押下したときの結果

$ xev -event keyboard | grep -A 4 KeyPress
KeyPress event, serial 37, synthetic NO, window 0x5000001,
    root 0x4b0, subw 0x0, time 77117780, (896,832), root:(1200,1200),
    state 0x0, keycode 97 (keysym 0x5c, backslash), same_screen YES,
    XLookupString gives 1 bytes: (5c) "\"
    XmbLookupString gives 1 bytes: (5c) "\"
    XFilterEvent returns: False

X-Windows System ではこの一連の流れを XKB (X Keyboard Extension) が担っている。キーボードからの入力を機能に変換する仕組みである。

次に、各キーの配置情報を保持するジオメトリ情報を確認してみよう。
以下のディレクトリに保存されている。

	$ ls -F --group-directories-first /usr/share/X11/xkb/geometry/
	digital_vndr/  ataritt  fujitsu    kinesis    nokia      sony         thinkpad
	sgi_vndr/      chicony  hhk        macintosh  northgate  steelseries  typematrix
	README         dell     hp         microsoft  pc         sun          winbook
	amiga          everex   keytronic  nec        sanwa      teck

ここから、日本語キーボードのレイアウトのジオメトリを探してみる。
まずは "日本語" を意味する "jp", "jap" で検索を絞り込む。

	$ grep -Ei 'jp|jap' /usr/share/X11/xkb/geometry/* 2>/dev/null
	/usr/share/X11/xkb/geometry/fujitsu:    // This is an approximate layout for a Fujitsu Japanese keyboard.
	/usr/share/X11/xkb/geometry/fujitsu:    description= "Fujitsu Japanese keyboard";
	/usr/share/X11/xkb/geometry/hhk:xkb_geometry "jp1" {
	/usr/share/X11/xkb/geometry/hhk:xkb_geometry "jp2" {
	/usr/share/X11/xkb/geometry/hhk:xkb_geometry "jp3" {
	/usr/share/X11/xkb/geometry/hhk:xkb_geometry "jp4" {
	/usr/share/X11/xkb/geometry/macintosh:// Aluminium Keyboard, JIS model (Japanese, 112 keys)
	/usr/share/X11/xkb/geometry/macintosh:                {  <KP0>, "KPDT",   0 },  { <JPCM>, "KPDT",   3.5 },
	/usr/share/X11/xkb/geometry/sanwa:    // http://www.sanwa.co.jp/product/syohin.asp?code=SKB-KG3BK
	/usr/share/X11/xkb/geometry/sanwa:    // http://www.sanwa.co.jp/zooma/keybord/SKB-KG3BK/
	/usr/share/X11/xkb/geometry/sanwa:    // http://www.sanwa.co.jp/product/syohin.asp?code=SKB-KG3W
	/usr/share/X11/xkb/geometry/sanwa:    // http://www.sanwa.co.jp/zooma/keybord/SKB-KG3SW/
	/usr/share/X11/xkb/geometry/sanwa:    // http://www.sanwa.co.jp/product/syohin.asp?code=SKB-KG3SV
	/usr/share/X11/xkb/geometry/sanwa:    // http://www.sanwa.co.jp/zooma/keybord/SKB-KG3SV/
	/usr/share/X11/xkb/geometry/sun:xkb_geometry "t6jp" {
	/usr/share/X11/xkb/geometry/sun:xkb_geometry "type6jp" {
	/usr/share/X11/xkb/geometry/sun:    include "sun(t6jp)"
	/usr/share/X11/xkb/geometry/sun:    description= "Sun Type6 Japanese keyboard";
	/usr/share/X11/xkb/geometry/sun:xkb_geometry "type7jp" {
	/usr/share/X11/xkb/geometry/sun:    include "sun(t6jp)"
	/usr/share/X11/xkb/geometry/sun:    description= "Sun Type7 Japanese keyboard";
	/usr/share/X11/xkb/geometry/typematrix:// Japan / Korean 106 keys mode.
	/usr/share/X11/xkb/geometry/typematrix:    description = "TypeMatrix EZ-Reach 2030 USB (106:JP mode)";

富士通, HHK（ハッピー・ハッキング・キーボード）, マッキントッシュ, サンワサプライ, サンマイクロシステムズ, タイプマトリックスなどの製品が有るようだ。

次に、前述の2つのキーを含むジオメトリを探してみよう。

	$ grep -E '<(AE13|AB11)>' /usr/share/X11/xkb/geometry/* 2>/dev/null
	/usr/share/X11/xkb/geometry/dell:		{<AB09>, "NORM", 1}, {<AB10>, "NORM", 1}, {<AB11>, "NORM", 1}, {<RTSH>, "RTSH", 1}};};
	/usr/share/X11/xkb/geometry/fujitsu:		   <AB11>, { <RTSH>, "RTSH" },
	/usr/share/X11/xkb/geometry/fujitsu:		   <AB11>, { <RTSH>, "RTSH" },
	/usr/share/X11/xkb/geometry/macintosh:                { <AE12>, "NORM",   3.5 }, { <AE13>, "NORM",   3.5 },
	/usr/share/X11/xkb/geometry/macintosh:                { <AB11>, "NORM",   3.5 }, { <RTSH>, "RTSH",   3.5 }
	/usr/share/X11/xkb/geometry/nec:		    <AB06>, <AB07>, <AB08>, <AB09>, <AB10>, <AB11>,
	/usr/share/X11/xkb/geometry/sanwa:                   <AE11>, <AE12>, <AE13>, { <BKSP>, "TBBK" }
	/usr/share/X11/xkb/geometry/sanwa:                   {<AB09>, color="grey20"}, {<AB10>, color="grey20"}, <AB11>,
	/usr/share/X11/xkb/geometry/sony:		    <AB06>, <AB07>, <AB08>, <AB09>, <AB10>, <AB11>,
	/usr/share/X11/xkb/geometry/typematrix:// — Calc key becomes <AE13>
	/usr/share/X11/xkb/geometry/typematrix:// — <BKSL> key becomes <AB11>
	/usr/share/X11/xkb/geometry/typematrix:            keys { <AE06>, <AE07>, <AE08>, <AE09>, <AE10>, <AE11>, <AE12>, <AE13> };
	/usr/share/X11/xkb/geometry/typematrix:            keys { <AB06>, <AB07>, <AB08>,

両方とも含むのは macintosh, sanwa, typematrix の 3つだけだ。

このうち、 macintosh は applealu_jis という名前のモデルで 109A より後継の 112 日本語フルサイズ・キーボードを元にしているようだが、なぜか { 変換, 無変換 } キーが { ハングル, ハンジャ } だったり、全角/半角 キーがなかったりするのであまり良くなさそうだった。

typematrix は tm2030USB-106 というモデルが該当するが、レイアウトが特殊な奇をてらったキーボードらしく、「ぜんぜん違うな…」という印象を受けた。

残る sanwa は sanwaskbkg3 というモデル名で、3,000円前後の低価格帯の USBキーボードであるようだ。"サンワサプライ SKB-KG3" という製品。これは概ね良かった。が、フルサイズ・キーボードではなく、テンキーがないコンパクト・タイプのキーボード・レイアウトになっている。

【参考】SKB-KG3BK【コンパクトキーボード（ブラック）】｜サンワサプライ株式会社

筆者が試した Surface Go やラップトップ PC ではレイアウトが近いのでほとんど問題ない。が、そうでない場合はこれで良いか注意が必要だ。もし、OADG109A フルサイズ・キーボードを使用している場合には、それに合わせたジオメトリが欲しくなるだろう。

🔵 jp106 のモデル定義が存在しない問題

では sanwaskbkg3 が気に入らない場合はどうすればいいだろうか？
OADG109A フルサイズ・キーボードに一致したレイアウトにしたい場合には、
XKB の公式サイト xkeyboard-config から最新の pc ジオメトリ・ファイルをダウンロードしてきて更新する。

実はこの最新バージョンでは設定ファイルの jp106 ジオメトリ情報が復活⁷ されており、正しい情報になっている。(Arch Linux にて確認）
これをダウンロードしてきてインストールするか、簡易的には geometry/pc と rules/evdev を置き換えれば、 jp106 をモデルに指定することで正常に機能するようになる。ただし、あくまでも 106 仕様であるため Super, Menu キーは存在しない。

Linux Mint 22.3 (Zena) では Ubuntu 24.04LTS (Noble) のパッケージを使用しており、XKB の設定ファイルは xkb-data パッケージにまとめられているのだが、これのバージョンが古く、上記の更新が含まれていない。逆に言えば、 "常に最新" のパッケージが供給される Arch Linux などのローリング・アップデートを採用しているディストリビューションでは、パッケージ・マネージャーからインストールした xkeyboard-config パッケージでも、この現象は起きないだろう。jp106 モデル、およびそのジオメトリが使用できる。

🔵 モデルの変更とレイアウトの確認

筆者の場合は sanwaskbkg3 でほぼ同じキー配列になったので、適用してみる。
以下のように setxkbmap コマンドを使用する。

	$ setxkbmap -model sanwaskbkg3 -layout jp -variant OADG109A
	$ setxkbmap -print
	xkb_keymap {
		xkb_keycodes  { include "evdev+aliases(qwerty)"	};
		xkb_types     { include "complete"	};
		xkb_compat    { include "complete+japan"	};
		xkb_symbols   { include "pc+jp(OADG109A)+inet(evdev)+terminate(ctrl_alt_bksp)"	};
		xkb_geometry  { include "sanwa(sanwaskbkg3)"	};
	};

項目 xkb_geometry がしっかり sanwaskbkg3 になっていることを確認する。
存在しないジオメトリを指定したり、タイポでしくじってもエラーが出ないので、-print オプションで確認が必要だ。⁸

すると、キーボードの設定画面で [レイアウト表示] ボタンを押したときの構成は以下のようになった。

ちゃんと ¥ や \ キーも有り、反応する。いい感じだ。

✍️ 【余談】 定義は有るが選べないものもある:

-- 🖱️ クリックで開く --

筆者はこのいろいろなジオメトリを試してみる過程で fujitsu ファイルに定義のある "140" を選択しようとしたが、失敗してしまった。
以下のようなコマンドだ。

	$ setxkbmap -model 140 -layout jp -variant OADG109A
	→ 結果：ダメ。

	$ setxkbmap -geometry 'fujitsu(140)' -layout jp -variant OADG109A
	→ 結果：こっちもダメ。

他にもこういったバリエーションをいくつか試したが、いずれも効果なし。 setxkbmap -print を実行すると、変更前の値のままになっている。
（あるいは、 xkb_geometry が pc104 などのデフォルト値になる）

これは XKB の仕組みとして、ルール・ファイルという仕組みがあるため。 /usr/share/X11/xkb/rules/evdev に有るファイルで、XKB が扱う以下の情報をまとめてひとつの "モデル" や "レイアウト" として定義したファイルのこと。

項目名	説明
xkb_geometry	キーボードの物理的な外観（キーの配置、サイズ、パネルの形状）を定義。
xkb_keycodes	スキャンコード（ハードウェア信号）を、XKB内部で扱うキー名（e.g. <AD01>）に紐付け。
xkb_symbols	キー名に実際の文字や機能（e.g. a, A, Escape）を割り当てる。最も頻繁にカスタマイズされる。
xkb_types	修飾キーとの組み合わせ動作（例：Shift を押した時にどのレベルの文字を出すか）を定義。
xkb_compat	互換性の制御。修飾キー（Ctrl, Alt等）の挙動や LED（Caps Lock等）の点灯条件などを定義。

この定義があるがゆえに、ユーザーは個別に各項目を指定しなくとも、一般的な製品を使う限りは「モデル名とレイアウトの指定のみ」で済ませることができる。

このルール・ファイルそのものを Xorg が参照している訳ではなく、 evdev がデバイスを認識する際に用い、 xkbcomp コマンドを使ってコンパイルされたものが X11 へと渡される。

evdev は Linux カーネルの「デバイスからの入力イベントを処理するドライバ」だ。 evdev によって認識、処理されてからキーコードや XKB のデバイス情報に加工された情報が Xorg に渡される形になる。

次のコマンドで、ここで定義されている有効な全モデル名が確認できる。

	$ localectl list-x11-keymap-models

問題の fujitsu "140" はこのルール・ファイルに存在しない。モデル名の定義がないのだ。なので、 -model オプションに指定はできない。 -geometry オプションには指定できるが、ルール・ファイルに存在しないので上述したような他の項目との明確な紐付けができなく、無効な定義であると判断されるようだ。結果、 setxkbmap コマンドでエラーが出ることはないものの、デフォルトのモデルである pc104, pc105 などにフォールバックされてしまう。

　　【参考】manpage - xkeyboard-config(7)

🔵 設定を永続化させるには？

setxkbmap コマンドでの設定変更は一時的なものに過ぎない。
再起動されたら、元に戻ってしまう。

永続的な設定の変更には、通常 localectl という systemd のコマンドを用いて設定する必要がある。

🔹非 Debian系での実行結果

  $ localectl set-x11-keymap jp sanwaskbkg3 OADG109A terminate:ctrl_alt_bksp
  $ localectl status
  System Locale: LANG=ja_JP.UTF-8
      VC Keymap: jp106
     X11 Layout: jp
      X11 Model: sanwaskbkg3
    X11 Variant: OADG109A
    X11 Options: terminate:ctrl_alt_bksp
  $

💡【HINT】systemd を採用していない場合は？:
systemd を採用していないディストリビューションの場合は ~/.xprofile または ~/.xinitrc を使うか、Xorg の設定ファイル /etc/X11/xorg.conf.d/00-keyboard.conf のようなファイルを作るか、書き換えるという形になると思う。

ただし、
Linux Mint の場合、どのエディションでも systemd が使われているのだが、 localectl コマンドを使って設定しようとすると次のようにエラーを吐いて止まってしまう。

🔹Debian 系 Linux での実行結果

	$ localectl set-x11-keymap jp jp106 OADG109A terminate:ctrl_alt_bksp
	Setting X11 and console keymaps is not supported in Debian.

これは Linux Mint の元となっているディストリビューション Debian が独自のキーボード設定機能を持っているためだ。 Ubuntu、あるいは Ubuntu を元にしているディストリビューションの多くでも同様。
そちらでの設定と被るため、意図的に systemd の localectl での設定をさせないようにしている。
Debian 系でのキーボード設定は GUI から設定するか、 CLI でやる場合は以下のようになる。

	$ sudo dpkg-reconfigure keyboard-configuration

ただし、Linux Mint 22.3 ではモデル jp106 が選択肢に出なかった。
…どうやらここでも XKB の定義を参考に作られているらしく、上述した jp106 のモデル定義が無い問題のため、選択できなくなっている模様だ。つまり、一度 sanwaskbkg3 などに変更してしまうと、元に戻せなくなるおそれがあるので注意。( jp106 になっていた場合）

さらに、
この Debian のキーボード設定ユーティリティは風変わりになっており、 initramfs を生成し直して仮想コンソール上でのキーボードを設定する。GUI (X-Window System) が起動する前のロー・レベルな設定からやるということだ。そのセッションでは XKB の モデル/ジオメトリ へ情報をすぐに反映させず、次回再起動時に反映する。これらの点に注意して使用すること。

非 Debian 系で localectl コマンドで設定をした場合、設定ファイル /etc/X11/xorg.conf.d/00-keyboard.conf および /etc/vconsole.conf が自動的に書き換わる。
前者は再起動しても設定が適用されるようにする Xorg の設定ファイル。後者は仮想コンソール上でのキーボードの設定ファイルだ。

これで再起動後も OADG109A 準拠の日本語キーボードが使える。
（ただし、仮想コンソール上では XKB の拡張仕様である OADG109A バリアント設定が適用されないため、厳密には 106 キーの仕様となり ¥ キーの挙動などが異なる）

🔶 Onboard のレイアウトを修正する

さて、
謎はすべて解けた。

本記事の目的は達せられた。
達せられたのだが…

もうひとつ、やらなければならない仕事がある。
そう。筆者がこの問題を調べるきっかけとなった、オンスクリーン・キーボードのレイアウトを正しい姿に変えることだ。筆者の場合は、 Linux Mint なので最初から入っている Onboard を変えることにする。

例えば Fcitx の "仮想キーボード" など、他のオンスクリーン・キーボードを 使っている／使いたい 場合は、やり方が異なるのでそちらのマニュアルを読もう。

少々、長くなる上にタイトルと趣旨が変わってきてしまうので別記事にした。以下。

💡 【HINT】 Fcitx の仮想キーボードに関して:

-- 🖱️ クリックで開く --

Linux Mint で日本語設定をした場合にデフォルトでインストールされる Fcitx4 には仮想キーボードがある。…ただし、これは俺ちゃんの環境では画面に対して小さすぎて使えなかった。

大きくして使う方法もなくはないのだが…　止めておいたほうがいい。
この機能は入力メソッドと統合されておらず、不完全だったため Fcitx5 では削除されているからだ。加えて、 Fcitx4 はメンテナンス・モードのみなので将来的には使えなくなるだろう。

Fcitx5 では、仮想キーボードはアドオンとして "DBus ベースの仮想キーボードバックエンド" として裏側で動作し、 API を提供するだけの形に変わっているようだ。これを利用して KDE Plasma デスクトップ環境（ KWin ウィンドウ・マネージャー）ではシステム標準の入力として扱い、連携して使用することができる。

ただし、 Fcitx5 とその仮想キーボードを同時には使用できない、などの問題があった。だが、最近有志によって開発された Fcitx-OSK で解決した模様。
このように、まだまだ様々な環境では安定しない Wayland コンポジッターを元にしたデスクトップ環境ではこの手のアクシビリティ機能は遅れを取りがちだが、ようやく事態が動き出したようには感じる。

それって Linux Mint Cinnamon エディションだけに起こるの？:
いいや。 LM だけではないし、 Cinnamon だけでもない。Xfce エディションでも MATE でも、Ubuntu や Fedora などの別のディストリビューションでも起きる。
この現象が起きるのは X-Window System (Xorg, X11, X86Free など) がキーボードを取り扱う XKB という仕組みがが関わっている。（記事後半で解説）
Wayland についても経路が違うが XKB を用いている。筆者は常用しておらず未確認だが、おそらく同様にこの現象が起きると思われる。なぜなら誰もこの問題を長年根本的に解決していない状態だからだ。おそらく Wayland でも引き継がれてしまっていることだろう。 ↩
オンスクリーン・キーボードとは:
例えば、指に障害がある。寝たきりなどの理由でキーボードが使用できない方々がマウスなどのポインタ機器を利用して文字入力を行ったり、健常者でもタブレット端末やスマートフォンなどのタッチ・スクリーン搭載機種でハードウェアのキーボードを代替してキー入力操作をするときに役立つユーティリティ・ソフトウェアのこと。 ↩
「＊ちゃんと＊調べ始めたって」どういう意味？:
実は俺ちゃんはこの問題は以前から認識していた。たぶん、5年以上前から。
でも入力時に特に支障がなかったし、ちゃんと調べるのもめんどかったので軽く調べただけで放置していた。その頃は仕事では US配列キーボード 中心だったし。…たぶん、みんなそんな感じなんだと思う。だから今まで誰もこれを気にせず、解決しようとしなかったのだと。
でも、最近手に入れたタッチ・スクリーンに対応したタブレットPC、 Surface Go で遊んでいたときに Onboard が使えなかったので調べたら、ここが根本的な原因だった。そこで重い腰を上げて調べ始めたってわけ。 ↩
じゃあ jp106 ならどうなの？:
という疑問が浮かんでくるはずだ。賢明な読者諸君なら。
しかし、後述するが、Linux Mint 22系や Ubuntu 24.04LTS 未満で使用されている XKB のパッケージは jp106 のジオメトリ定義が消されてしまっており、正しく動作しない。 pc105 などのデフォルトのジオメトリにフォールバックされてしまう。 GitLab の公式ページから最新のものを取得してきて更新すれば正しく動作するが、それも 109A とは違うので Super や Menu キーが無いという問題が残る。 ↩
ASCIIとかな文字部分がJIS配列の正体:
どうやら "JIS配列" と日本で言われているのはこの ASCII文字とかな文字の部分のみ であるようだ。公式にそんな定義がされている仕様書は見当たらなかったが…。おそらく、業界の慣例なのだろうと思われる。これらのキーが JIS X 6002 に準拠していれば "JIS配列" を名乗ることができるらしい。例えば、 NEC PC-98 シリーズのキーボードなどは制御キーが OADG 106 や 109A キーボードとはかなり異なるが、これも "JIS配列" と呼ばれている。ASCII, かな文字部分は、ほとんど同様である。 ↩
別の国用の刻印:
例えば以下の製品はフランス, ドイツ, スペイン, 北欧, スイス, イギリスに対応したキーキャップが売られていて差し替えることができる。
【参考】ISO Cherry Profile Dye-Sub PBT Full Set Keycap Set - White Mint – Keychron France ↩
jp106 ジオメトリの変遷について:
具体的には以前は存在しており、一度消されたが、 xkeyboard-config 2.43 での作業によって復活された。韓国仕様の kr106, ブラジル仕様の abnt2 についても同時に 削除→復活 している。
詳細な経緯はよくわからないが、ざっと追ってみると、
━━━━━━━━━━━━━━━━━━━━━━━━━
1: 2009-02-27 に abnt2, jp106, kr106 国別の対応コードが evdev ルール・ファイルなどから削除。
2: ただし、ジオメトリは残った。「しばらくしたら削除する」と書かれている。
3: 2020-03-23 に「11年は"しばらく"には十分だ」としてジオメトリが削除。
4: 2021-11-10 の「kr106 が使えない」という Issue がきっかけで復活。
5: 2024-10-01 リリースの ver.2.43 で公開。頒布。
━━━━━━━━━━━━━━━━━━━━━━━━━
のような経緯で 削除→復活 された模様。どうも古い XFree86 関連のコードを削除するリファクタリングか何かの過程でなぜか不要と判断され削除対象に選ばれ、11年後に別の人物によって完全に削除されたという経緯のようだ。
11年前にどういう判断があったのかは詳しくはわからないが…　安易に削除されてしまったのは残念に思う。ただし、確かに人々が使用しているのは既に古い 106 仕様ではなく、109A 仕様であるので、ある意味では正しいのだが。それでも主要な 104, 105 と 106/109 とではキーの数自体が違い、かけ離れているのでまだ必要だったのだ。決して 105 の亜種などではないのだから。 ↩
-print オプションと -query オプションの違い:
なお、 -query というオプションもあるが、これは現在『設定値に指定されている値』を表示するのみで、それが正しく適用されたかは関知しないようだ。タイポなどであり得ない、おかしな値を設定してもそのまま表示されてしまう。よって常に -print を使用するべきだ。-print オプションは xkbcomp (XKB キーマップコンパイラ ) を通してみてフォールバックされるか否かというところまで観察できる。 ↩