On every keymap notify event, the keymap should be refreshed, which
fetches the required X11 atoms. A big keymap might have a few hundred of
atoms.
A profile by a user has shown this *might* be slow when some intensive
amount of keymap activity is occurring. It might also be slow on a
remote X server.
While I'm not really sure this is the actual bottleneck, caching the
atoms is easy enough and only needs a couple kb of memory, so do that.
On the added bench-x11:
Before: retrieved 2500 keymaps from X in 11.233237s
After : retrieved 2500 keymaps from X in 1.592339s
Signed-off-by: Ran Benita <ran@unusedvar.com>
Where resolve_keysym fails we warn but use the otherwise uninitialized variable
as our keysym. That later ends up in the keymap as random garbage hex value.
Simplest test case, set this in the 'us' keymap:
key <TLDE> { [ xyz ] };
And without this patch we get random garbage:
./build/xkbcli-compile-keymap --layout us | grep TLDE:
key <TLDE> { [ 0x018a5cf0 ] };
With this patch, we now get NoSymbol:
./build/xkbcli-compile-keymap --layout us | grep TLDE:
key <TLDE> { [ NoSymbol ] };
For me, installing pytest for libxkbcommon is a bit problematic, so I
end up skipping it which is not great.
Switch to unittest which is built in to Python. It's not as nice as
pytest but good enough in this case.
Note: I was too lazy to switch the plain asserts to unittest
assertions...
Signed-off-by: Ran Benita <ran@unusedvar.com>
MacOS doesn't have eaccess/euidaccess but it does have unistd.h, so let's
include it to silence the R_OK redefinition compiler warnings.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
../src/context.c:57:9: warning: variable 'err' is used uninitialized whenever
'if' condition is true [-Wsometimes-uninitialized]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
mkdtmp, rmdir and unlink are in unstd.h on MacOS. Since including that it
doesn't hurt us on Linux, let's do it without ifdefs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
While this tool is useful for users starting with a new keyboard layout, it is a
somewhat bad fit for libxkbcommon. It's the only python tool, we don't even
install it yet (because we're not sure yet what it's supposed to do) and there's
a potential for it to expand into more corner cases.
The only tie it has to libxkbcommon is that it templates the data files that
libxkbcommon reads, but those files are effectively public API.
Let's remove this tool from there and instead move it to a separate git
repository where it can go its own way.
This reverts commit d00cf64dbc
PATH_MAX is not POSIX and can be missing on some systems, notably Windows (which
provides MAX_PATH instead tough) and Hurd. Let's define it to a sane value where
missing, i.e. the one it's defined to in limits.h. Except on Windows where
we're limited to 260.
Fixes https://github.com/xkbcommon/libxkbcommon/issues/180
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of using the unpredictable chocolatey let's just handle it
ourselves. The versions are pinned but that's arguably good.
Fixes https://github.com/xkbcommon/libxkbcommon/issues/179
Signed-off-by: Ran Benita <ran@unusedvar.com>
It's a niche use-case but basically the same as adding symbols, so let's go with
a general handwavy explanation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This tool set ups the required directory structure and template files to add new
keyboard layouts or options. For example, run like this:
xkbcli-scaffold-new-layout --layout 'us(myvariant)' --option 'custom:foo'
This will up the evdev rules file, the evdev.xml file, the symbols/us file and
symbols/custom file in $XDG_CONFIG_HOME so that the user has everything in place
and can start filling in the actual key mappings.
This tool is currently uninstalled until we figure out whether it's useful.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This completes the usual triplet of configuration locations available for most
processes:
- vendor-provided data files in /usr/share/X11/xkb
- system-specific data files in /etc/xkb
- user-specific data files in $XDG_CONFIG_HOME/xkb
The default lookup order user, system, vendor, just like everything else that
uses these conventions.
For include directives in rules files, the '%E' resolves to that path.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, a 'symbols/us' file in path A would shadow the same file in path B.
This is suboptimal, we rarely need to hide the system files - we care mostly
about *extending* them. By continuing to check other lookup paths, we make it
possible for a XDG_CONFIG_HOME/xkb/symbols/us file to have sections including
those from /usr/share/X11/xkb/symbols/us.
Note that this is not possible for rules files which need to be manually
controlled to get the right bits resolved.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Streamline the code a bit - instead of handling all the if (!file) conditions
handle the case of where we have a file and jump to the end.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
'xkbcli compile-keymap' doesn't work unless we ninja install first. But for a
test that's to be run from the test directory, that's not a useful option so
let's call the binary directly. The script adds the meson builddir to the PATH
anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Let's not have our tests fail if the user has an incompatible
$XDG_CONFIG_HOME/xkb directory.
libxkbcommon has fallbacks when XDG_CONFIG_HOME isn't set so we need to override
this with a real directory instead of just unsetting it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ran Benita
Peter Hutterer
hhb