キーマップとアプリケーション自体

キーマップとアプリケーション自体

私のCentOSシステムでは、Ctrl+Alt+F1名前はX Windowsセッションとして表示されますが、:0他のシステムでもCtrl+Alt+F7同じことができます。 FnキーがXセッションとTTYにどのようにマッピングされるかを決定するには?

関連していますが違います。Ctrl + Alt + F <Num>を押すとどうなりますか?

ベストアンサー1

キーマップとアプリケーション自体

実際のキーとコード認識は、キーボードマップでプログラムされた内容によって異なります。この隣に2つの異なる関連するキーボードマッピングは次のとおりです。2つの異なるコードセット。

  • X11サーバーには、キーボードデバイスの入力イベントを変換する独自のキーマップがあります。これは⎈ Control、++形式のコードを⎇ Altアクティブなカーネル仮想端末を変更するための要求(X11サーバーから発行)に変換します。Fn
  • カーネルに組み込まれた端末エミュレータには、キーボードデバイスの入力イベントを変換する独自のキーマップがあります。これ⎇ Altにより、コードの + 形式をアクティブなカーネル仮想端末を変更する要求に変換します。コードは通常同じアクションにマッピングされますが、このマッピングは必須ではありません。Fn⎈ Control⎈ Control

少なくとも多くのLinuxオペレーティングシステムでは、後者のキーマップは構成メカニズムを介して前者から派生し、システム管理者は単一の場所から1つのマッピングのみを構成します。しかし、実際の地図は2つです。

どれが適用されるかは、どのカーネル仮想端末が有効になっているかによって異なります。これは、X11 サーバーがカーネル仮想端末を効果的に「所有」するプロトコルを使用するためです。

  • この端末に切り替えると、X11サーバーはKVTサブシステムをカーネル自体の内蔵端末エミュレータがキーボード入力デバイスから完全に切断されるモードに切り替えるか、仮想端末をネイティブキーコードモードに切り替えてカーネルを構築します。端末ではシミュレータでマッピングが行われず、
  • X11サーバーは、端末が別の場所に切り替えられると、この操作をキャンセルします。

これにより、X11サーバーはカーネルに組み込まれているターミナルエミュレータとさまざまなI / Oデバイスを共有できます。 (この共有プロトコルは、使用しているI / Oデバイスにカーネル内蔵端末エミュレータがまったく接続されていない場合は必要ありません。)I / Oデバイスを担当する場合、キーマップはカーネルが組み込まれているときに適用されます。端末エミュレータでは、対応するキーマップが適用されます。

これは、X11サーバーがどのカーネル仮想端末を最初に「所有」するかを決定する方法を示しています。これはX11サーバーに依存するためです。 3つの方法があります。

  • 最初に使用可能なカーネル仮想端末を割り当てます。このモードで⎇ AltX11セッションに切り替えるために使用される+キーボードコードは、システムが起動する他の項目とサービスが開始される順序によって実行時に異なる場合があります。 Fn
    • たとえば、カーネル仮想端末1〜4に固定されたTUIログインサービス(実行中または類似のサービス)がある場合、gettyX11サーバーはKVT番号5を使用可能な次の仮想端末として見つけるため、⎇ Alt+F5はキーボードコードです。
    • たとえば、システムが要求時に(ユーザーがKVTに切り替えたときに)TUIログインサービスを開始し、まだサービスが開始されていない場合、X11サーバーはKVT番号1を使用可能な次の仮想端末として見つけるため、⎇ Alt+F1はキーボードコードです。
  • コマンドラインで指定されたカーネル仮想端末を割り当てます(表面的には予約済み)。サーバープログラムのコマンドライン引数の1つは、使用するカーネル仮想端末の数です。したがって、引数がここに与えられると、vt7+⎇ AltF7キーボードコードです。
  • 現在カーネル仮想端末を使用しています。これは、KVTのTUIログインセッションにログインし、そのログインセッションでX11サーバーを起動する(現在はより珍しい)場合です。

数十年前に、X11サーバーをKVT番号7に割り当てることが一般的な慣行でした。しかし、これはその後、いくつかのオペレーティングシステムで変更されました。これでもないオリジナルこれは、少なくともLinuxオペレーティングシステムの世界では一般的な慣行です。 (もちろん、マルチコア仮想端末という概念はLinuxよりも先に来たものであり、実際のUnicesには異なる慣例があります。)

10年前にFedoraオペレーティングシステムスイートで変更されました。人々は、画面を消去+再描画せずに、またはX11サーバーが引き継ぐ準備が整うまで、オペレーティングシステムの起動の最初にシステムが起動画面を表示し続けたかったからです。 X11サーバーが別のサーバーにありました。 KVT から起動し、強制的にスイッチを強制的に実行する前に、カーネルの組み込み端末エミュレータは、KVT 番号 1 からの起動により別の表示モードに入ると出てくる点滅を引き起こします。起動画面で無効になったKVT番号1からカーネルの組み込み端末エミュレータを起動せずに使用するように変更されました。それその後、X11サーバーはKVTを使用してスプラッシュ画面からGUIログイン画面にシームレスに切り替えます。

(人々はこれらの変更をsystemdとして誤って考えています。実際、これはsystemdよりも数年前に発生し、Fedoraがupstartを使用していた間に発生しました。年後にsystemdが最初に開始されたときにこの変更が行われ、systemdがupstartによって実行された操作を複製できなくなり、TUIログインセッションとX11サーバー間でKVT 1がクラッシュしました。

したがって、一部のオペレーティングシステムでは、X11サーバーがKVT番号7を使用し、他のオペレーティングシステムではKVT番号1を使用することがわかります。

Debian 9などの他のシステムでは、KVT番号1が割り当てられているのがX11サーバー以外のグラフィックサブシステムであり、プライマリGUIログインインターフェイスに使用され、セカンダリX11サーバーが割り当てられます。その他すべてのGUIログインセッションに使用されるKVT。 ( ⎈ Control+) ⎇ Alt+ はF1デフォルトの GUI ログイン画面に切り替え、( ⎈ Control+) ⎇ Alt+ はF2(存在する場合は最初) GUI ログインセッションに切り替えます.

追加読書

おすすめ記事