Surrogates (0xd800..0xdfff) are not handled by utf32_to_utf8 and by xkb_keysym_to_utf32. They are invalid code points on utf32 and utf8 but used for code pairs in utf16. is_valid_utf8 works as it should and return numbers inside this range as invalid.

Please, see my fork about it. I recoded the utf32_to_utf8 and is_valid_utf8 to be more straightforward (and easier to maintain). As an added benefit we get an utf8_to_utf32 function.

Regards,
André

Hello,

libxkbcommon currently fails to build on hurd because it uses uint64_t without including stdint.h, please see attached patch.

Samuel
patch.txt

Hi,

On my Chromebook I mapped Shift+Alt+Left/Right/Up/Down to Home/End/PgUp/PgDown in xkeyboard-config as the Chromebook keyboard lacks these keys.
To be able to use these hotkeys on Chromium, Firefox and LibreOffice in X session I needed to add the RedirectKey function.
I would love to be able to use the RedirectKey action also in a Wayland session.

I would add that in X session this feature does have an issue: when holding down the hotkey which was mapped with RedirectKey action (e.g. holding Alt+Shift+Down for a few seconds) then sometimes the system will stop responding to the hotkey and it'll take a few seconds for the system to respond to another key press, maybe it can described as the RedirectKey action overflow some buffer and then it takes a few seconds to flush it.

See my changes to xkeyboard-config <- Edit: Updated link the patch

Hi,

I'm tried to compile libxbcommon on osx but yacc throws an syntax error. I tried both bison 2.3 and byacc 1.9 20141128. Reverting 7ec0093 fixed the issue for me.

To whom it may concern,
there is a discrepancy the line defining Ocaron:

Currently it reads
#define XKB_KEY_Ocaron 0x10001d1 /* U+01D2 LATIN CAPITAL LETTER O WITH CARON */
To be consistent with the contract set out in the preamble of the file it should read:
#define XKB_KEY_Ocaron 0x10001d1 /* U+01D1 LATIN CAPITAL LETTER O WITH CARON */

Also wrong, but harder to decide:
#define XKB_KEY_approxeq 0x1002248 /* U+2245 ALMOST EQUAL TO */
#define XKB_KEY_notapproxeq 0x1002247 /* U+2247 NOT ALMOST EQUAL TO */
could be
#define XKB_KEY_approxeq 0x1002248 /* U+2248 ALMOST EQUAL TO */
#define XKB_KEY_notapproxeq 0x1002249 /* U+2249 NOT ALMOST EQUAL TO */
or
#define XKB_KEY_approxeq 0x1002245 /* U+2245 APPROXIMATELY EQUAL TO */
#define XKB_KEY_notapproxeq 0x1002247 /* U+2247 NEITHER APPROXIMATELY NOR ACTUALLY EQUAL TO */
I tend to support the second option.

Thanks in advance for fixing.
Cheers,
Keve

I’ve been working on fixing numlock handling in i3 (see i3/i3#2346) when I encountered the following behavior which baffles me.

On the test computer, I start X11 without specifying a layout, i.e. using the “us” layout:

$ xmodmap -pke | grep KP_1
keycode  87 = KP_End KP_1 KP_End KP_1

Then, I run the following program:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <stdbool.h>
#include <stdint.h>
#include <err.h>

#include <xcb/xproto.h>
#include <xcb/xkb.h>
#include <xkbcommon/xkbcommon.h>
#include <xkbcommon/xkbcommon-x11.h>

struct xkb_keymap *xkb_keymap = NULL;

bool load_keymap(void) {
    int scr;
    xcb_connection_t *conn = xcb_connect(NULL, &scr);
    if (conn == NULL) {
        errx(EXIT_FAILURE, "conn");
    }
    static uint8_t xkb_base_event;
    static uint8_t xkb_base_error;

    if (xkb_x11_setup_xkb_extension(conn,
                                XKB_X11_MIN_MAJOR_XKB_VERSION,
                                XKB_X11_MIN_MINOR_XKB_VERSION,
                                0,
                                NULL,
                                NULL,
                                &xkb_base_event,
                                &xkb_base_error) != 1)
        errx(EXIT_FAILURE, "Could not setup XKB extension.");

    struct xkb_context *xkb_context;
        if ((xkb_context = xkb_context_new(0)) == NULL) {
            errx(EXIT_FAILURE,"Could not create xkbcommon context\n");
            return false;
        }

    struct xkb_keymap *new_keymap = NULL;
    int32_t device_id;
    if ((device_id = xkb_x11_get_core_keyboard_device_id(conn)) > -1) {
        if ((new_keymap = xkb_x11_keymap_new_from_device(xkb_context, conn, device_id, 0)) == NULL) {
            errx(EXIT_FAILURE,"xkb_x11_keymap_new_from_device failed\n");
            return false;
        }
    } else {
            errx(EXIT_FAILURE,"unhandled");
    }
    xkb_keymap_unref(xkb_keymap);
    xkb_keymap = new_keymap;

    return true;
}

struct resolve {
    /* |bind|’s keysym (translated to xkb_keysym_t), e.g. XKB_KEY_R. */
    xkb_keysym_t keysym;

    /* The xkb state built from the user-provided modifiers and group. */
    struct xkb_state *xkb_state;
};

static void add_keycode_if_matches(struct xkb_keymap *keymap, xkb_keycode_t key, void *data) {
    if (key != 87) {
        return;
    }
    const struct resolve *resolving = data;
    printf("add_keycode_if_matches(key=%d)\n", key);
    xkb_keysym_t sym = xkb_state_key_get_one_sym(resolving->xkb_state, key);
    printf("sym = %d, resolving->keysym = %d\n", sym, resolving->keysym);
}


int main() {
    load_keymap();
    struct xkb_state *dummy_state = xkb_state_new(xkb_keymap);
    if (dummy_state == NULL) {
        errx(EXIT_FAILURE, "Could not create XKB state, cannot translate keysyms.\n");
    }

    const xkb_keysym_t keysym = xkb_keysym_from_name("KP_1", XKB_KEYSYM_NO_FLAGS);
    if (keysym == XKB_KEY_NoSymbol) {
        errx(EXIT_FAILURE, "Could not translate string to key symbol: KP_1");
    }

    xkb_mod_mask_t mask = (xkb_mod_mask_t) ((1ull << xkb_keymap_num_mods(xkb_keymap)) - 1u);
    printf("mask = %d, XCB_KEY_BUT_MASK_LOCK = %d, masked = %d\n", mask, XCB_KEY_BUT_MASK_LOCK, XCB_KEY_BUT_MASK_LOCK&mask);

    (void)xkb_state_update_mask(
        dummy_state,
        XCB_KEY_BUT_MASK_LOCK /* xkb_mod_mask_t base_mods, */,
        0 /* xkb_mod_mask_t latched_mods, */,
        0 /* xkb_mod_mask_t locked_mods, */,
        0 /* xkb_layout_index_t base_group, */,
        0 /* xkb_layout_index_t latched_group, */,
        XCB_XKB_GROUP_1 /* xkb_layout_index_t locked_group, */);

    struct resolve resolving = {
        .keysym = keysym,
        .xkb_state = dummy_state,
    };
    xkb_keymap_key_for_each(xkb_keymap, add_keycode_if_matches, &resolving);
}

The output of the program is:

$ pkg-config --modversion xkbcommon
0.6.1
$ gcc -o poc poc.c $(pkg-config --cflags --libs xkbcommon xkbcommon-x11 xcb xcb-xkb)
$ ./poc
mask = 2097151, XCB_KEY_BUT_MASK_LOCK = 2, masked = 2
add_keycode_if_matches(key=87)
sym = 65436, resolving->keysym = 65457

I would have expected the program to print 65457 (= 0xffb1 = KP_1), but instead it prints 65346 (= 0xff9c = KP_End).

What am I doing wrong here? Why is specifying XCB_KEY_BUT_MASK_LOCK in base_mods in xkb_state_update_mask seemingly a noop?

Thanks!

xev shows a very interesting behavior, when holding Ctrl it always generates latin key events even if the currently active layout is Russian (which only has cyrillic letters).

KeyPress event, serial 28, synthetic NO, window 0x2c00001,
    root 0x1cf, subw 0x0, time 287760, (-807,-100), root:(1140,0),
    state 0x10, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XmbLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2c00001,
    root 0x1cf, subw 0x0, time 287884, (-807,-100), root:(1140,0),
    state 0x10, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x2c00001,
    root 0x1cf, subw 0x0, time 507942, (-490,157), root:(1457,257),
    state 0x2010, keycode 40 (keysym 0x6d7, Cyrillic_ve), same_screen YES,
    XLookupString gives 2 bytes: (d0 b2) "в"
    XmbLookupString gives 2 bytes: (d0 b2) "в"
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2c00001,
    root 0x1cf, subw 0x0, time 508090, (-490,157), root:(1457,257),
    state 0x2010, keycode 40 (keysym 0x6d7, Cyrillic_ve), same_screen YES,
    XLookupString gives 2 bytes: (d0 b2) "в"
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x2c00001,
    root 0x1cf, subw 0x0, time 309258, (-1349,-37), root:(598,63),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x2c00001,
    root 0x1cf, subw 0x0, time 310271, (-1349,-37), root:(598,63),
    state 0x14, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (04) ""
    XmbLookupString gives 1 bytes: (04) ""
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2c00001,
    root 0x1cf, subw 0x0, time 310441, (-1349,-37), root:(598,63),
    state 0x14, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (04) ""
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2c00001,
    root 0x1cf, subw 0x0, time 310973, (-1349,-37), root:(598,63),
    state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x2c00001,
    root 0x1cf, subw 0x0, time 538564, (-342,490), root:(1605,590),
    state 0x2010, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x2c00001,
    root 0x1cf, subw 0x0, time 540366, (-342,490), root:(1605,590),
    state 0x2014, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (04) ""
    XmbLookupString gives 1 bytes: (04) ""
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2c00001,
    root 0x1cf, subw 0x0, time 540546, (-342,490), root:(1605,590),
    state 0x2014, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (04) ""
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2c00001,
    root 0x1cf, subw 0x0, time 540946, (-342,490), root:(1605,590),
    state 0x2014, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

I know this might sound like an xkcd comic, but please bear with me, this is truly very useful, because applications can have keyboard shortcuts and they work regardless of the currently active layout. For example, in terminal Ctrl+C, Ctrl+D, Ctrl+Shift+C do not work unless you configure an English keyboard layout on your computer.

I was told xev uses xlib to get this behavior, and it looks like libxkbcommon doesn't follow this behavior.

scancode: 0x25 release: 0 clean_sym: Control_L composed_sym: Control_L mods: numlock glfw_key: LEFT CONTROL
scancode: 0x28 release: 0 clean_sym: Cyrillic_ve composed_sym: Cyrillic_ve mods: ctrl+numlock glfw_key: UNKNOWN
scancode: 0x28 release: 1 clean_sym: Cyrillic_ve mods: ctrl+numlock glfw_key: UNKNOWN
scancode: 0x25 release: 1 clean_sym: Control_L mods: ctrl+numlock glfw_key: LEFT CONTROL

This was originally reported for kitty terminal, the author suggested this to be fixed in libxkbcommon instead.

There is a trailing comma in xkeyboard-config at symbols/level5:40 which leads to an error in the current parser.
Looking at parser.y and the declaration of SymbolsBody it seems that leading commas are allowed but trailing ones aren't. I'm guessing that is a mistake.
Allowing empty SymbolsVarDecl should solve the issue (allowing empty SymbolsBody might be removed).

[root@farm505 libxkbcommon-master]# ./autogen.sh
autoreconf: Entering directory .' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4 ${ACLOCAL_FLAGS} autoreconf: configure.ac: tracing configure.ac:32: warning: The macroAC_FOREACH' is obsolete.
configure.ac:32: You should run autoupdate.
autoconf/general.m4:196: AC_FOREACH is expanded from...
aclocal.m4:2707: _AM_SET_OPTIONS is expanded from...
aclocal.m4:2445: AM_INIT_AUTOMAKE is expanded from...
configure.ac:32: the top level
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, build-aux'. libtoolize: copying filebuild-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, m4'. libtoolize: copying filem4/libtool.m4'
libtoolize: copying file m4/ltoptions.m4' libtoolize: copying filem4/ltsugar.m4'
libtoolize: copying file m4/ltversion.m4' libtoolize: copying filem4/lt~obsolete.m4'
autoreconf: running: /usr/bin/autoconf --force --warnings=all
configure.ac:32: warning: The macro AC_FOREACH' is obsolete. configure.ac:32: You should run autoupdate. autoconf/general.m4:196: AC_FOREACH is expanded from... aclocal.m4:2707: _AM_SET_OPTIONS is expanded from... aclocal.m4:2445: AM_INIT_AUTOMAKE is expanded from... configure.ac:32: the top level autoreconf: running: /usr/bin/autoheader --force --warnings=all autoreconf: running: automake --add-missing --copy --force-missing --warnings=all Makefile.am: C objects in subdir butAM_PROG_CC_C_O' not in configure.ac' Makefile.am:82: user targetsrc/xkbcomp/parser.h' defined here...
automake: ... overrides Automake target `src/xkbcomp/parser.h' defined here
autoreconf: automake failed with exit status: 1

After setting my keybindings according to this thread [1], I often see the following error in the terminal, when I start programs:

xkbcommon: ERROR: Key "<LFSH>" added to modifier map for multiple modifiers; Using Lock, ignoring Shift

I'm using Fedora 26. This error appeared already some time ago and with setting my settings back and reset them, the errors disappeared. But what's even more strange is, that this influences applications so the don't run properly anymore. In Geary I have to enter my passwords repeatedly as the password popup reappears every time I enter my password, and Lollypop is completely responsiveless. This was also the case when I encountered this bug before, but this time, setting back my keyboard settings doesn't improve the situation.

If you need more information, I'll try to help!

[1] https://bugzilla.gnome.org/show_bug.cgi?id=777723

Building libxkbcommon-0.7.2 on OS X, with xquartz for X11 and fink for other build tools (bison, doxygen)...

  CC       src/libxkbcommon_x11_la-keymap-priv.lo
In file included from src/keymap-priv.c:27:
In file included from ./src/keymap.h:86:
./xkbcommon/xkbcommon.h:1772:5: warning: declaration is marked with '\deprecated' command but does not have a deprecation attribute [-Wdocumentation-deprecated-sync]
 * @deprecated Use xkb_state_key_get_consumed_mods2() instead.
   ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./xkbcommon/xkbcommon.h:1782:55: note: add a deprecation attribute to the declaration to silence this warning
                                   xkb_mod_mask_t mask);
                                                      ^
                                                        __AVAILABILITY_INTERNAL_DEPRECATED

This bug was reported by a tr_TR.UTF-8 locale user: https://bugzilla.gnome.org/show_bug.cgi?id=774374 .

I found out that under this locale the strcasecmp() call in keysym.c:compare_by_name() doesn't work as expected and we fail to find some keysym names. For instance, this sample program:

#include <stdio.h>
#include <locale.h>
#include <xkbcommon/xkbcommon.h>

static void
print_keysym (const char *name)
{
  xkb_keysym_t keysym = xkb_keysym_from_name (name, XKB_KEYSYM_NO_FLAGS);
  printf ("0x%x\n", keysym);
}

int
main (int argc, char **argv)
{
  if (argc != 2)
    {
      printf ("usage: %s <keyname>\n", argv[0]);
      return 0;
    }

  print_keysym (argv[1]);

  setlocale(LC_ALL, "");

  print_keysym (argv[1]);

  return 0;
}

when executed like LC_ALL=tr_TR.UTF-8 ./a.out i yields
0x69 0x0

I guess this is a glibc/locale bug since the keysym names are all just ASCII strings, but maybe libxkbcommon should use a different way to do this that doesn't rely on locale specific behavior?

I've recently added support in mutter to get the host X server's keymap with xkb_x11_keymap_new_from_device() when running nested:

https://git.gnome.org/browse/mutter/tree/src/backends/x11/meta-backend-x11.c#n567

mutter then sends this keymap to its wayland clients, including an xwayland instance. When xwayland tries to compile this keymap it errors out.

Nearly at the end of the build I get the following:

GEN doc/html
/bin/sh: line 4: 25382 Done ( cat doc/Doxyfile; echo "INPUT = README.md doc/quick-guide.md doc/compat.md xkbcommon/xkbcommon.h xkbcommon/xkbcommon-names.h xkbcommon/xkbcommon-x11.h xkbcommon/xkbcommon-compose.h"; echo "OUTPUT_DIRECTORY = /tmp/SBo/libxkbcommon-0.8.2/doc" )
25383 Segmentation fault | ./scripts/doxygen-wrapper "/usr/bin/doxygen" - "/tmp/SBo/libxkbcommon-0.8.2"
make[1]: *** [Makefile:2389: doc/html] Error 139
make[1]: Leaving directory '/tmp/SBo/libxkbcommon-0.8.2'
make: *** [Makefile:1023: all] Error 2

Besides this there is a typo at line 216, being a "\n", in file
xkbcommon-compose.h

Where doxygen seems to fail on as well !

br,

Simon,
Slackware-current, 02-01-2019

/src/xkbcomp/parser.y:48.17-24: syntax error, unexpected identifier, expecting string

There is a bug with Keysym to Unicode translation for values of Keysym > 0x01000000. The real range is a bit more strict than the code that deals with it on xkb_keysym_to_utf32 use.

To speed up the translations of Keysyms with values inside keysymtab, I suggest the use of range boundaries, like what you can find on my fork.

Best regards,
André

In xkb_types "complete" of test/data/keymaps/host.xkb, FOUR_LEVEL_KEYPAD is defined twice and both of the two definitions are identical one another.

I'm wondering if the duplication might be unnecessary for the x11comp test.

I raise this question because the test fails on my Mac OS X 10.9.5, leaving the message:

Multiple definitions of the FOUR_LEVEL_KEYPAD key type
Earlier definition ignored
...
round-trip test failed: dumped map differs from original
length: dumped 56580, original 56965

in test-suite.log.

In addition, the dumped map is just a host.xkb which only differs in the multiplicity of the definition from the original; the former only contains a single definition of FOUR_LEVEL_KEYPAD.

Actually, as indicated by the message and the dumped map, if I resolve the duplication by deleting one of the definitions in the original file, the test readily passes.

Is the duplication really needed?

Thanks

If you press e.g. the '+' key on the keypad, and the ctrl key is pressed, then the xkb API will report the ctrl modifier as consumed, even though ctrl doesn't change the interpretation of the key (i.e. same keysym).

I'd expect that ctrl is not considered consumed in this case.

The APIs I was looking at were the following:

xkb_keysym_t sym = xkb_state_key_get_one_sym(state, code);
xkb_mod_index_t index = xkb_keymap_mod_get_index(keymap, XKB_MOD_NAME_CTRL);
int active = xkb_state_mod_index_is_active(state,  index, XKB_STATE_MODS_DEPRESSED);
int consumed = xkb_state_mod_index_is_consumed(state, code, index);

active and consumed can both be 1 for code==XKB_KEY_KP_Add.

for setting keymap on X server via xkbcommon-x11.

Modern convertible laptops typically use an accelerometer for automatic display rotation, and may have a hardware switch or button to turn on/off the automatic rotation.

Currently, there is a keycode for handling switches, SW_ROTATE_LOCK, but no keycode for buttons. A switch has distinct states, while for a button (which has press/release events) the state has to be tracked in software.

Proposed patch for adding this keycode, KEY_ROTATE_LOCK_TOGGLE (0x231), to the kernel:
https://patchwork.kernel.org/patch/10052039/

If an invalid input is passed as argument to utf32_to_utf8, i.e., any number >= 0x80000000, it will return an invalid encoded utf8 string and if the resulting string is used with printf functions family members the result would be undefined.

Perhaps, an appropriate behavior should be the return of an empty string and number of chars == 1 for numbers >= 0x80000000.

Better yet would be to return the same as above for any number > 0x10FFFF but, for concerns about compatibility with the previous standard, the anterior suggestion would suffice.

I have tried to compile xkbcommon with --enable-x11. Configuring says error. When I added some dependencies, configuring complete. You need to make check for pkgconfig(x11) and pkgconfig(xau) if the option --enable-x11 enabled.
build_log_plus_config_log.zip

Hi Ran

Daniel and I have been talking briefly about dead-keys and compose-keys with xkbcommon. As I got a request to handle it in kmscon, I was wondering what the current state of xkbcommon regarding these features is? As I don't know any way how to query dead-keys from kmscon, any ideas how we could support that? Or if it is already possible, could you give me some hints how to do it?

Daniel wasn't opposed to handling it in the library itself. Thing is, it requires us to return multiple keysyms in case a dead-key didn't take effect. Our current API allows returning multiple keysyms, but afaik this was still indented for single key-presses. If we re-use it for dead-keys/etc., we no longer have the guarantee that the returned keys were generated by a single key-press (might be an important hint for shortcuts). Ideas?

Regarding compose-keys, I actually have no idea what they do. Luxury of having an English alphabet, I guess. But hints welcome here, too!

Cheers
David

On release 0.8.0, it appears that -I flags from pkg-config aren't passed in.

$ pkg-config --cflags xcb-xkb
-I/home/user/.local/include
$ ninja
[1/2] Compiling C object 'interactive-x11@exe/test_interactive-x11.c.o'.
FAILED: interactive-x11@exe/test_interactive-x11.c.o 
cc  -Iinteractive-x11@exe -I. -I.. -I../src -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -std=c99 -O0 -g -fvisibility=hidden -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast -Wshadow -Wlogical-op -Wdate-time -Wwrite-strings -Wno-documentation-deprecated-sync -include config.h -MMD -MQ 'interactive-x11@exe/test_interactive-x11.c.o' -MF 'interactive-x11@exe/test_interactive-x11.c.o.d' -o 'interactive-x11@exe/test_interactive-x11.c.o' -c ../test/interactive-x11.c
../test/interactive-x11.c:29:21: fatal error: xcb/xkb.h: No such file or directory
compilation terminated.
ninja: build stopped: subcommand failed.
$ ls ~/.local/include/xcb/xkb.h 
/home/user/.local/include/xcb/xkb.h

EDIT: This only seems to be true for the meson build -- if I run autogen.sh and then configure && make as usual, it installs correctly.

According to the docs All i need to do is

meson setup build
ninja -C build

But the first command fails.

pi@raspberrypi:~ $ git clone https://github.com/xkbcommon/libxkbcommon.git
Cloning into 'libxkbcommon'...
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 11851 (delta 0), reused 1 (delta 0), pack-reused 11845
Receiving objects: 100% (11851/11851), 6.01 MiB | 1.84 MiB/s, done.
Resolving deltas: 100% (8160/8160), done.
Checking connectivity... done.
pi@raspberrypi:~ $ cd libxkbcommon/
pi@raspberrypi:~/libxkbcommon $ ls
autogen.sh    m4                 README.md      xkbcommon.pc.in
bench         Makefile.am        scripts        xkbcommon-x11.map
configure.ac  meson.build        src            xkbcommon-x11.pc.in
doc           meson_options.txt  test
fuzz          NEWS               xkbcommon
LICENSE       PACKAGING          xkbcommon.map
pi@raspberrypi:~/libxkbcommon $ meson setup build
-bash: meson: command not found
pi@raspberrypi:~/libxkbcommon $ sudo apt-get install meson
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  ninja-build
The following NEW packages will be installed:
  meson ninja-build
0 upgraded, 2 newly installed, 0 to remove and 42 not upgraded.
Need to get 135 kB of archives.
After this operation, 626 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://mirrordirector.raspbian.org/raspbian/ jessie/main ninja-build armhf 1.3.4-1.2 [68.8 kB]
Get:2 http://mirrordirector.raspbian.org/raspbian/ jessie/main meson all 0.21.0-1 [66.5 kB]
Fetched 135 kB in 0s (162 kB/s)
Selecting previously unselected package ninja-build.
(Reading database ... 130138 files and directories currently installed.)
Preparing to unpack .../ninja-build_1.3.4-1.2_armhf.deb ...
Unpacking ninja-build (1.3.4-1.2) ...
Selecting previously unselected package meson.
Preparing to unpack .../meson_0.21.0-1_all.deb ...
Unpacking meson (0.21.0-1) ...
Processing triggers for man-db (2.7.5-1~bpo8+1) ...
Setting up ninja-build (1.3.4-1.2) ...
Setting up meson (0.21.0-1) ...
pi@raspberrypi:~/libxkbcommon $ meson setup build
Error during basic setup:

[Errno 2] No such file or directory: '/home/pi/libxkbcommon/setup'
pi@raspberrypi:~/libxkbcommon $ ls
autogen.sh    m4                 README.md      xkbcommon.pc.in
bench         Makefile.am        scripts        xkbcommon-x11.map
configure.ac  meson.build        src            xkbcommon-x11.pc.in
doc           meson_options.txt  test
fuzz          NEWS               xkbcommon
LICENSE       PACKAGING          xkbcommon.map
pi@raspberrypi:~/libxkbcommon $ meson setup build
Error during basic setup:

[Errno 2] No such file or directory: '/home/pi/libxkbcommon/setup'
pi@raspberrypi:~/libxkbcommon $ mkdir setup
pi@raspberrypi:~/libxkbcommon $ meson setup build
Error during basic setup:

[Errno 2] No such file or directory: '/home/pi/libxkbcommon/build'
pi@raspberrypi:~/libxkbcommon $ mkdir build
pi@raspberrypi:~/libxkbcommon $ meson setup build
Error during basic setup:

Neither directory contains a build file meson.build.
pi@raspberrypi:~/libxkbcommon $

Currently it is taken as a single path. For compatibility with libX11.

If I pass for example "el_GR.ISO8859-7" to xkb_compose_table_new_from_locale() and enable XKB_LOG_LEVEL_DEBUG (in XKB context) I see the following error message:

"/usr/share/X11/locale/iso8859-7/Compose:84:29: string literal is not a valid UTF-8 string"

Is this by design or a bug? I could not find in the documentation any info about this. The locale path do contain these locales. I am guessing there are people that use them?

I remember one bug report about Qt's custom Compose table parser - https://bugreports.qt.io/browse/QTBUG-35770 There was a bug that it was asserting on non-utf8 locales, due to programming error. This bug report indicates that there are users that for some reason use non-utf8 locales.

../src/xkbcomp/parser.y:34:26: fatal error: xkbcomp-priv.h: No such file or directory
compilation terminated.
Makefile:1507: recipe for target 'src/xkbcomp/parser.lo' failed
make[1]: *** [src/xkbcomp/parser.lo] Error 1
make[1]: *** Waiting for unfinished jobs....
In file included from ../src/xkbcomp/keywords.c:34:0:
../src/xkbcomp/parser-priv.h:33:20: fatal error: parser.h: No such file or directory
compilation terminated.
In file included from ../src/xkbcomp/scanner.c:25:0:
../src/xkbcomp/parser-priv.h:33:20: fatal error: parser.h: No such file or directory
compilation terminated.

Full logs:
http://build.gnome.org/continuous/buildmaster/builds/2017/07/31/29/build/log-libxkbcommon.txt

GNOME components that depend on xkbcommon-x11 started to fail to build after commit a3c907d with this error:

Package 'xcb-xkb>=1.10', required by 'xkbcommon-x11', not found

See full build log for Mutter, available here.

Can something be done about it. I know on X it is a hard limit but can libxkbcommon be modified for allowing more than 4 keyboards on WL?

Thanks in advance.

Presumably after a recent update to either xkbcomp or xserver. In retrospect, this test is not very future proof... But it is useful, so I should check out the diff.

When trying to compile on osx, I get: ld: unknown option: --version-script=./xkbcommon.map. With this option removed from the Makefile and after working around #23 I can built everything just fine.

For the composed key "õ", the name is returned correctly, "otilde".

For the composed key "ũ", the name returned is "U0169".

Another example: "ŕ" should return "racute", but returns "U0155".

According with the header xkbcommon-keysyms.h:

 * Mnemonic names for keysyms are defined in this file with lines
 * that match one of these Perl regular expressions:
 *
 *    /^\#define XKB_KEY_([a-zA-Z_0-9]+)\s+0x([0-9a-f]+)\s*\/\* U+([0-9A-F]{4,6}) (.*) \*\/\s*$/
 *    /^\#define XKB_KEY_([a-zA-Z_0-9]+)\s+0x([0-9a-f]+)\s*\/\*\(U+([0-9A-F]{4,6}) (.*)\)\*\/\s*$/
 *    /^\#define XKB_KEY_([a-zA-Z_0-9]+)\s+0x([0-9a-f]+)\s*(\/\*\s*(.*)\s*\*\/)?\s*$/

Looking at the define for utilde:

#define XKB_KEY_utilde                        0x03fd  /* U+0169 LATIN SMALL LETTER U WITH TILDE */

Maybe the regular expression is jumping the "utilde" and grabbing the "0169"?

The Lets Encrypt certificate for https://www.xkbcommon.org/ expired on October 17. Please renew and install the updated certificate.

Hey, I've made an attempt at redesigning the project homepage.
You can take a look at the result here.

Regarding the technologies used, it is just bootstrap (CSS only), I've also used the iosevka font.

The source resides here, it is licensed under the MIT license so you are free to do as you please with it.

Hope you like it!

Reported this issue on gnome-terminal under wayland :

https://bugzilla.gnome.org/show_bug.cgi?id=764825

Could it be related to xkbcommon?

The PACKAGING file says it is recommended to offer libxkbcommon and libxkbcommon-x11 as separate packages.

It's easy enough to build libxkbcommon without libxkbcommon-x11 by using --disable-x11. But I can't see how to do the reverse.

If I've already built and installed libxkbcommon without libxkbcommon-x11, and then later I want to install libxkbcommon-x11, I don't want to have to rebuild and reinstall all of libxkbcommon too.

There should be a way to build libxkbcommon-x11 only, against an already-installed libxkbcommon. If this capability already exists, please let me know; maybe the documentation needs improving. If it doesn't, it should be added.

I was debugging an key binding issue, and while doing so, I temporarily added de, and de(neo) to my keyboard layouts. This resulted in the following keymap:

rules: evdev
model: pc105+inet
layouts: de,de,us,us,
variants: ,neo,dvorak-alt-intl,,
options:

Using this combination broke (at least) the dvorak-alt-intl layout, and I couldn't do things like Ctrl+Shitf+C to copy in gnome-terminal, when using that layout group. Regular typing did work however. Removing neo2 fixed the issue.

I experimented some with the interactive evdev test. I don't know how things are expected to work, but the behaviour seems odd to me. See below.

Apply the following patch (adds option to test/interactive-evdev):

diff --git a/test/interactive-evdev.c b/test/interactive-evdev.c
index b0b9e62..1858693 100644
--- a/test/interactive-evdev.c
+++ b/test/interactive-evdev.c
@@ -46,6 +46,7 @@ struct keyboard {
 
 static bool terminate;
 static int evdev_offset = 8;
+static xkb_layout_index_t layout_index = 0;
 static bool report_state_changes;
 static bool with_compose;
 static enum xkb_consumed_mode consumed_mode = XKB_CONSUMED_MODE_XKB;
@@ -120,6 +121,10 @@ keyboard_new(struct dirent *ent, struct xkb_keymap *keymap,
         goto err_fd;
     }
 
+    xkb_state_update_mask(state,
+                         0, 0, 0,
diff --git a/test/interactive-evdev.c b/test/interactive-evdev.c
index b0b9e62..1858693 100644
--- a/test/interactive-evdev.c
+++ b/test/interactive-evdev.c
@@ -46,6 +46,7 @@ struct keyboard {
 
 static bool terminate;
 static int evdev_offset = 8;
+static xkb_layout_index_t layout_index = 0;
 static bool report_state_changes;
 static bool with_compose;
 static enum xkb_consumed_mode consumed_mode = XKB_CONSUMED_MODE_XKB;
@@ -120,6 +121,10 @@ keyboard_new(struct dirent *ent, struct xkb_keymap *keymap,
         goto err_fd;
     }
 
+    xkb_state_update_mask(state,
+                         0, 0, 0,
+                         0, 0, layout_index);
+
     if (with_compose) {
         compose_state = xkb_compose_state_new(compose_table,
                                               XKB_COMPOSE_STATE_NO_FLAGS);
@@ -384,7 +389,7 @@ main(int argc, char *argv[])
 
     setlocale(LC_ALL, "");
 
-    while ((opt = getopt(argc, argv, "r:m:l:v:o:k:n:cdg")) != -1) {
+    while ((opt = getopt(argc, argv, "r:m:l:v:o:k:n:i:cdg")) != -1) {
         switch (opt) {
         case 'r':
             rules = optarg;
@@ -412,6 +417,14 @@ main(int argc, char *argv[])
                 exit(EXIT_FAILURE);
             }
             break;
+       case 'i':
+            errno = 0;

Then run

sudo ./build/interactive-evdev -l us -v dvorak-alt-intl

When I press (on qwerty keyboard) Ctrl+Shift+i which in dvorak terms is Ctrl+Shift+c, I get the result:

keysyms [ Control_L        ] unicode [  ] layout [ English (Dvorak alternative international no dead keys) (0) ] level [ 0 ] mods [ ] leds [ ] 
keysyms [ Shift_L          ] unicode [  ] layout [ English (Dvorak alternative international no dead keys) (0) ] level [ 0 ] mods [ Control ] leds [ ] 
keysyms [ C                ] unicode [ � ] layout [ English (Dvorak alternative international no dead keys) (0) ] level [ 1 ] mods [ -Shift Control ] leds [ ] 

But when I combine it with neo (or any other layout, for that matter), as below:

sudo ./build/interactive-evdev -l de,us -v neo,dvorak-alt-intl -i 1

The result of the same key sequence is:

keysyms [ Control_L        ] unicode [  ] layout [ German (Neo 2) (0) ] level [ 0 ] mods [ ] leds [ Group 2 ] 
keysyms [ Shift_L          ] unicode [  ] layout [ German (Neo 2) (0) ] level [ 0 ] mods [ Control ] leds [ Group 2 ] 
keysyms [ C                ] unicode [ � ] layout [ English (Dvorak alternative international no dead keys) (1) ] level [ 1 ] mods [ -Shift Control ] leds [ Group 2 ] 

I don't know if this has anything to do with the actual issue, however.

It seems like when mapping an action to a key it lose its repeat value.
It would be nice if we can manually set this value.
Currently this feature also broken in X so I manually set the repeat with xset r keycode.

I should add that I requested this feature as complementary to my other request to add RedirectKey action and if it will not be added then I don't need the repeat feature.

See my changes to xkeyboard-config <- Edit: Updated link the patch

If I try to compile the 0.7.2 release, I get this error:
https://gist.github.com/rezso/df5d227c044e03f6451ef2396dd2f84f
What's wrong?

The qwerty-lafayette is a new qwerty-bqsed french layout that is not yet reqdy to be included in the xkb maps. Still, it would be desirqble for users to be able to install this layout (see issue fabi1cazenave/qwerty-lafayette#15 in French).

The diff required to install this layout system-wide is: https://gist.github.com/fabi1cazenave/2171d69d3d8d6e298225

The problem with this diff is that it is not possible to create a package from it because it requires patching the rules files. It would be desirable if libxkbcommon could read additional rule files in directories.

For example, /usr/share/X11/xkb/rules/evdev.d/lafayette.lst and /usr/share/X11/xkb/rules/evdev.d/lafayette.xml could be read as part of /usr/share/X11/xkb/rules/evdev.lst and /usr/share/X11/xkb/rules/evdev.xml respectively.

It would be even better if libxkbcommon could read files from ~/.xkb/rules/evdev.d/*.{lst,xml}

I'm trying to allow sway to store a layout per window. I figured that currently active layout is stored in xkb_state.

As I understand, libxkbcommon doesn't have any "layout-changed" hook, so I need to manually check active layout every time xkb_state being touched (is that correct?).

Then questions come down to:

1. How to get an id of currently active layout?
2. How to set the currently active layout with an id.

The closest I could find was this issue, but they're getting layout name with xkb_keymap_layout_get_name(), whereas I guess I gonna need an index; and I couldn't find in xkbcommon.h anything with infix layout_set anyway.

For now xkb_state_layout_get_name returns a long name, like Russian,
but can you add a function that returns a short name, like ru?

Similar to xkb_state_layout_name_is_active, but not checks active layout name, returns it instead.
This is useful for XKB plugins (keyboard layout switchers/indicators)

All the AST nodes which are allocated before the error are not freed. Admittedly we don't get many invalid keymaps, but unlike any other yacc parser I know of, this is not acceptable in a library.

We can use something like bison's %destructor or similar to free the discarded nodes.

In file src/keysym-utf.c:

    { 0x0abc, 0x2329 }, /*            leftanglebracket 〈 LEFT-POINTING ANGLE BRACKET */

    { 0x0abe, 0x232a }, /*           rightanglebracket 〉 RIGHT-POINTING ANGLE BRACKET */

At the same time in file keysymdef.h of xproto:

#define XK_leftanglebracket              0x0abc  /*(U+27E8 MATHEMATICAL LEFT ANGLE BRACKET)*/

#define XK_rightanglebracket             0x0abe  /*(U+27E9 MATHEMATICAL RIGHT ANGLE BRACKET)*/

I think that U+27E8 and U+27E9 codes are more relevant for angle brackets.

Proposed diff file:

diff --git a/src/keysym-utf.c b/src/keysym-utf.c
index ffe2cea..5fdae24 100644
--- a/src/keysym-utf.c
+++ b/src/keysym-utf.c
@@ -534,9 +534,9 @@ static const struct codepair keysymtab[] = {
     { 0x0ab7, 0x215a }, /*                  fivesixths ⅚ VULGAR FRACTION FIVE SIXTHS */
     { 0x0ab8, 0x2105 }, /*                      careof ℅ CARE OF */
     { 0x0abb, 0x2012 }, /*                     figdash ‒ FIGURE DASH */
-    { 0x0abc, 0x2329 }, /*            leftanglebracket 〈 LEFT-POINTING ANGLE BRACKET */
+    { 0x0abc, 0x27e8 }, /*            leftanglebracket 〈 LEFT-POINTING ANGLE BRACKET */
     { 0x0abd, 0x002e }, /*                decimalpoint . FULL STOP */
-    { 0x0abe, 0x232a }, /*           rightanglebracket 〉 RIGHT-POINTING ANGLE BRACKET */
+    { 0x0abe, 0x27e9 }, /*           rightanglebracket 〉 RIGHT-POINTING ANGLE BRACKET */
     /*  0x0abf                                  marker ? ??? */
     { 0x0ac3, 0x215b }, /*                   oneeighth ⅛ VULGAR FRACTION ONE EIGHTH */
     { 0x0ac4, 0x215c }, /*                threeeighths ⅜ VULGAR FRACTION THREE EIGHTHS */

Please see http://infra.in.zekjur.net/pipermail/i3-discuss/2013-August/001413.html and followups.

Apparently num lock must be turned off to type numbers.

The static inline popcount function in src/util.h conflicts with NetBSD's.
libxkbcommon has int popcount(uint32_t x) while NetBSD has a unsigned int popcount(unsigned int value) in libc.
Either adapt the signature or better rename it. Thanks!

Following info reported in https://bugreports.qt-project.org/browse/QTBUG-31527, it seems the problem comes from missing xkbcommon support for this.
Is this true?
My laptop has a broken up arrow key remapped with xmodmap. This works against Qt 4, but not with Qt 5.

Using libkxbcommon (with the systemd-evcat test tool) I observe:

xkbcommon: DEBUG: Compiling from RMLVO: rules 'evdev', model 'pc105', layout 'us,us', variant 'dvorak-intl', options 'grp:caps_toggle'
xkbcommon: DEBUG: Compiling from KcCGST: keycodes 'evdev+aliases(qwerty)', types 'complete', compat 'complete', symbols 'pc+us+us:2+inet(evdev)+capslock(grouplock)'

(notice the missing trailing comma in the variant). The effect is that I get two plain us keymaps. I would have expected either an error message/failing compilation or for the compiler to somehow make sense of the missing comma (as X does AFAIU).

With the trailing comma:

xkbcommon: DEBUG: Compiling from RMLVO: rules 'evdev', model 'pc105', layout 'us,us', variant 'dvorak-intl,', options 'grp:caps_toggle'
xkbcommon: DEBUG: Compiling from KcCGST: keycodes 'evdev+aliases(qwerty)', types 'complete', compat 'complete', symbols 'pc+us(dvorak-intl)+us:2+inet(evdev)+capslock(grouplock)'