コンテキストでは、WaylandでGNOMEを使用してFedora 39でComposeキーを処理したときに発生したバグを追跡しようとしています。ここそしてここ。しかし、私の質問はより一般的です。私は、Linuxデスクトップのキーボード入力という巨大なシステムで、すべての小さな部分がどのように調和しているのかを理解しようとしています。
私は次の作品について聞いたことがあります。
- Linuxカーネル
- evdev
- （lib）xkb共通
- バス
- ウェイランド
- GUIツールキット：GTK、Qt
- デスクトップ環境：GNOME、KDE（およびgsettingsなどの構成メカニズム）
- レガシーX11
どちらが何をしているのか少し混乱しています。
これは私のものです。考える私はこれが非常に間違っている可能性があることを理解しています。この場合、どうするかを知りたいです。
- Linuxカーネルはキーボードから（udev？？を介して）物理キー信号を取得し、それを「キーコード」に変換します。
- evdevは、カーネルから生の情報をより簡単に検索できるようにするライブラリ階層です（その文書から, "libevdev は本質的に /dev/input/eventX デバイスのステロイド読み取り(2)です。")
- libxkbcommonは、「キーコード」から「キー記号」へのマッピングを美しく表現したキーボードの説明を理解するライブラリです。
- Waylandプロトコル（具体的にwl_keyboard）は、キーコードを含む入力キーボードイベントを提供し、libxkbcommon形式でキーボード記述を取得する方法も提供します。
- X11も同様の機能を果たします。 「xkbcommon」という名前は、X11の一部であるxkbcommonの歴史に由来しています。今はもっと一般的ですが
- デスクトップ環境（私の場合はGNOME）では、設定GUIを使用してキーボードレイアウトを設定できます。レイアウトを正しく機能させるには、
wl_keyboard::keymapWaylandシンセサイザ（GNOME用Mutter）の出力にします。 - GTKなどのGUIツールキットは、Waylandプロトコルからキーコードとキーボード記述を取得し、libxkbcommonを使用してキーシンボルに変換し、何とか（どのように？）キーシンボルがUnicode文字になります。
IBusがこの図のどこに適しているかわかりません。それは何のために使用されますか？ libxkbcommonとどう違いますか？何か別のことをするのか、それとも競い合うのか？スタックのどの部分でそれを使用しますか？デスクトップ環境？シンセサイザーとは何ですか？ GUIツールキット？
~/.XComposeまた、ファイルをどこで読むのか理解できません。実際には、可能なキーシンボルのリストがどこに定義されているかさえ理解できません。