xkbcommon / libxkbcommon Goto Github PK
View Code? Open in Web Editor NEWkeymap handling library for toolkits and window systems
Home Page: https://xkbcommon.org
License: Other
keymap handling library for toolkits and window systems
Home Page: https://xkbcommon.org
License: Other
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.
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?
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é
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!
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!
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.
[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 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: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, build-aux'. libtoolize: copying file
build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, m4'. libtoolize: copying file
m4/libtool.m4'
libtoolize: copying file m4/ltoptions.m4' libtoolize: copying file
m4/ltsugar.m4'
libtoolize: copying file m4/ltversion.m4' libtoolize: copying file
m4/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 but
AM_PROG_CC_C_O' not in configure.ac' Makefile.am:82: user target
src/xkbcomp/parser.h' defined here...
automake: ... overrides Automake target `src/xkbcomp/parser.h' defined here
autoreconf: automake failed with exit status: 1
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/
Reported this issue on gnome-terminal under wayland :
https://bugzilla.gnome.org/show_bug.cgi?id=764825
Could it be related to xkbcommon?
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
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.
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.
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?
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.
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
.
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)
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 */
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 $
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
/src/xkbcomp/parser.y:48.17-24: syntax error, unexpected identifier, expecting string
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.
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}
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!
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.
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.
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"?
../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
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.
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
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
Russian layout, press "d", xev sees it as cyrillic "в":
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
English layout, press "Ctrl+d", xev sees it as "Ctrl+d":
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
Russian layout, press "Ctrl+d", xev sees it as latin "Ctrl+d" and not cyrillic "Ctrl+в":
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.
libxkbcommon
emits when I press Ctrl+d
in Russian layout: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.
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
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
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).
Hello,
libxkbcommon currently fails to build on hurd because it uses uint64_t without including stdint.h, please see attached patch.
Samuel
patch.txt
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é
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.
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
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
The Lets Encrypt certificate for https://www.xkbcommon.org/ expired on October 17. Please renew and install the updated certificate.
Currently it is taken as a single path. For compatibility with libX11.
for setting keymap on X server via xkbcommon-x11.
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.
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)'
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.
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:
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.
If I try to compile the 0.7.2 release, I get this error:
https://gist.github.com/rezso/df5d227c044e03f6451ef2396dd2f84f
What's wrong?
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!
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.