A simple script that creates a new layout with the given keysym replacing TLDE.
Then we compile a keymap and search for the keysym being assigned to TLDE and
bail if that fails.
The list of keysyms is manually maintained but we only need to add one or two to
spot-check whenever the xorgproto is updated.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
As of xorgproto commit 5dbb5b76597f [1], the 0x10081XXX keycode range is defined
for direct evdev kernel keycode mapping. For example, KEY_MACRO1 (0x290) is
mapped to 0x10081290. The format of the #define lines for these keys is
stable to allow for parsing:
#define XF86XK_FooBar _EVDEVK(0x123) /* optional comment */
Update our script so we detect these new lines. Our keysym generation is a
two-step process: makeheader and then makekeys. Replacing the key with its full
value in the makeheader script means we don't have to update makekeys to handle
the _EVDEVK macro and our header file is fully resolved.
[1] https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/23
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
rmlvos is the parent list which then fails during a list join because, well,
it's a list of lists.
Fixes#206
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Makes this test easier to run from the commandline. Where either of top_srcdir
or top_builddir isn't set, fill them in from the CWD or fail otherwise.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Ran Benita
Pierre Le Marre
Peter Hutterer
Simon Zeni
hhb