libxkbcommon
0.5.0
|
This document contains a quick walk-through of the often-used parts of the library. We will employ a few use-cases to lead the examples:
The snippets are not complete, and some support code is omitted. You can find complete and more complex examples in the source directory:
Also, the library contains many more functions for examining and using the library context, the keymap and the keyboard state. See the hyper-linked reference documentation or go through the header files in xkbcommon/ for more details.
Before we can do anything interesting, we need a library context. So let's create one:
The xkb_context contains the keymap include paths, the log level and functions, and other general customizable administrativia.
Next we need to create a keymap, xkb_keymap. This is an immutable object which contains all of the information about the keys, layouts, etc. There are different ways to do this.
If we are an evdev client, we have nothing to go by, so we need to ask the user for his/her keymap preferences (for example, an Icelandic keyboard with a Dvorak layout). The configuration format is commonly called RMLVO (Rules+Model+Layout+Variant+Options), the same format used by the X server. With it, we can fill a struct called xkb_rule_names; passing NULL chooses the system's default.
If we are a Wayland client, the compositor gives us a string complete with a keymap. In this case, we can create the keymap object like this:
If we are an X11 client, we are better off getting the keymap from the X server directly. For this we need to choose the XInput device; here we will use the core keyboard device:
Now that we have the keymap, we are ready to handle the keyboard devices. For each device, we create an xkb_state, which remembers things like which keyboard modifiers and LEDs are active:
For X11/XCB clients, this is better:
When we have an xkb_state for a device, we can start handling key events from it. Given a keycode for a key, we can get its keysym:
We can see which keysym we got, and get its name:
libxkbcommon also supports an extension to the classic XKB, whereby a single event can result in multiple keysyms. Here's how to use it:
We can also get a UTF-8 string representation for this key:
Of course, we also need to keep the xkb_state up-to-date with the keyboard device, if we want to get the correct keysyms in the future.
If we are an evdev client, we must let the library know whether a key is pressed or released at any given time:
The changed
return value tells us exactly which parts of the state have changed.
If is is a key-repeat event, we can ask the keymap what to do with it:
On the other hand, if we are an X or Wayland client, the server already does the hard work for us. It notifies us when the device's state changes, and we can simply use what it tells us (the necessary information usually comes in a form of some "state changed" event):
Now that we have an always-up-to-date xkb_state, we can examine it. For example, we can check whether the Control modifier is active, or whether the Num Lock LED is active:
And that's it! When we're finished, we should free the objects we've created: