まず朗報
Linux システム コンソールには、09 のツールを使用して管理できる、独自のキーボード マッピング セットがあります。 パッケージ、具体的には 18 そして 26 発見と 30 の場合 カスタマイズされたマッピングをロードします。 SuperUser の質問 Linux でコンソールのキーマップを変更するには?これらのツールの使用方法に関する適切な情報が記載された回答があります。
さて、悪い知らせです
これらのツールを使用すると、48 を使用せずに Linux コンソールでキーを再マップできるのは事実ですが、 または X が実行されている必要がある場合、のみ 仮想テキスト コンソールのキーマッピングに影響します。 X の XInput/evdev システムは入力デバイスから直接読み取り、独自の処理を行うため、この変更はグラフィカル環境にはまったく影響しません。
したがって、 56 の使用を避けたい場合は コンソールで再マッピングしてどこにでも適用するだけでは、うまくいかないのではないかと心配しています。実際、両方を再マッピングする必要があります コンソール (69 を使用) ) と X11 (71 のような方法を使用) )、どこでも同じキーボード レイアウトを使用します。
87 の解決策 遅さ (およびバグ、レイアウト切り替えを使用するデスクトップ環境では再マッピングがグリッチで永続的でないため) は、完全に新しい ランタイムの変更を適用するのではなく、以前に使用していたレイアウトに基づいたキーボード レイアウト。 X の起動時に、現在使用しているものの代わりに、新しく再マップされたレイアウトをロードします。 (現在はこれが 唯一 のようです 97 として、最近の Ubuntu (およびおそらく他のディストリビューション) のキーボード レイアウトを確実に変更する方法 はもう役に立ちません。)
カスタム 105 の定義と使用に関する情報 キーボード レイアウトについては、次を参照してください:
どちらも今年 (2014 年) に書かれたものなので、情報は最新のものである必要があります。 Ubuntu wiki の情報は、ほとんどの場合、すべてのディストリビューションに適用できるはずです。 X のシステム。
実際には、X11 であろうとなかろうと、システム全体に適用するのに十分低いレベルで再マッピングする方法があり、libinput の再マッピング用の UI を公開することを怠っている Wayland コンポジターの採用が見られるようになったため、それらはこれまで以上に重要になっています。サポート。
基本的に、X11 と Wayland が上にあるコンソールまたは evdev API に到達する前に、カーネルの入力レイヤーが生のスキャンコードをキーコードに変換する方法を再構成する必要があります。
私はそれを行う 2 つの方法を知っています:
<オール>
ハードウェア データベースを変更します (127 ) キーボードのエントリ。 udev では、規則ファイルを 132 に追加することでそれを行うことができます 144 でデータベースの再構築をトリガーする 、そして 157 経由で再起動せずに強制的に適用されます .
この ArchiWiki ページには完全な手順があり、X11 とコンソール入力の両方で機能すると明示的に述べています。
evdev デバイス上のキー イベントを、Wayland コンポジターなど、それらをサポートしていない evdev クライアントへのモンキー パッチ リマッピング サポートに再マッピングするために特別に作成された evdevremapkeys という名前のデーモンがあります。
基本的に、非標準の入力デバイスを補正する必要がある G15Daemon などのユーザー空間ドライバーと同じアプローチを使用します。 (evdev デバイスを開き、再マップする予定のイベントを飲み込み、デバイスでリッスンしている他の何もそれらを見ることができないようにし、163 を介して修正されたイベントを発行します。 ユーザー空間からカーネルレベルの入力デバイスを作成するための API。)