1

For context, I'm trying to track down a bug in Compose key handling that I experience on Fedora 39 with GNOME on Wayland, discussed here and here. However, my question is more general. I'm trying to understand how all the little bits fit together in the grand scheme of keyboard input on a Linux desktop.

I've heard about these pieces:

  • The Linux kernel
  • evdev
  • (lib)xkbcommon
  • IBus
  • Wayland
  • GUI toolkits: GTK, Qt
  • Desktop environments: GNOME, KDE (with their configuration mechanisms like gsettings)
  • The legacy X11

and I'm a bit lost as to which does what.

Here's what I think I understand, which may be very wrong — in which case I'd like to know how.

  • The Linux kernel gets signals for physical key presses from the keyboard (via udev??) and translates them into "key codes",
  • evdev is a library layer that makes the raw info from the kernel a bit easier to retrieve (from its documentation, "libevdev is essentially a read(2) on steroids for /dev/input/eventX devices")
  • libxkbcommon is a library that understands keyboard descriptions, which are glorified mappings from "key codes" to "key symbols".
  • The Wayland protocol (specifically wl_keyboard) provides input keyboard events with a key code, and also has a method to get the keyboard description in libxkbcommon's format.
  • X11 does something similar, and the "xkbcommon" name stems from the history of xkbcommon as some part of X11, though it is now more generic,
  • Desktop environments (in my case: GNOME) make the keyboard layout configurable via their configuration GUIs. For the layout to take effect, they serve it as the output of wl_keyboard::keymap in their Wayland compositor (which for GNOME is Mutter).
  • GUI toolkits (like GTK) get the key code and keyboard description from the Wayland protocol, use libxkbcommon to convert that to a key symbol… and then somehow (how?) the key symbol becomes a Unicode character.

And I don't understand where IBus fits in that picture. What is it used for? How does it differ from libxkbcommon? Does it do something different, or does it compete with it? Which parts of the stack use it? The desktop environment? Its compositor specifically? The GUI toolkits?

I also don't understand where ~/.XCompose files get read. Actually, I don't even understand where the list of possible key symbols is defined.

Improve this question
4
  • Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer.
    – killertofus
    Commented Apr 6 at 1:57
  • 2
    @killertofus I think OP is clear enough that their problem is to understand the pathway of a physical keystroke through the various software layers and how they relate to each other. Is this site limited to question of the “how can I do X?” kind, or is “how does X work?” permitted?
    – Gro-Tsen
    Commented Apr 15 at 9:41
  • 1
    This answer to a related question may be the closest thing which looks like an explanation of the “input method” part of the whole mess. (There is also a fragment of documentation for Gtk here, here and here.)
    – Gro-Tsen
    Commented Apr 15 at 10:34
  • 1
    This message on the debian-users mailing list provides some explanations as to what is going on at lower levels (kernel, xinput, xkb).
    – Gro-Tsen
    Commented Apr 15 at 10:38

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .