At least 2.3 (released 2006) which is the version shipped with macos
doesn't work. Reading the changelog I think 2.3a *should* work, so
require that.
Signed-off-by: Ran Benita <ran@unusedvar.com>
As the documentation for xkb_keymap_new_from_buffer() states, the "input string
does not have to be zero-terminated". The actual implementation however failed
with "unrecognized token/syntax error" when it encountered a null byte.
Fix this by allowing a null byte at the last position of the buffer. Anything
else is likely a client error anyway.
Fixes#307
This is backend-agnostic and the recommended way to invoke compilation.
This requires meson 0.55 (July 2020) and we only require 0.51 but at this point
I'm expecting most users who require the README instructions will have a
recent-enough meson anyway.
strdup() is the least likely call to fail here, let's move it to the bottom so
we don't need to worry about the allocated string.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
meson needs to know that the executable tools
link against libxkbcommon.dylib so that the
@rpath references used during the build/test phases
can be rewritten to full path names on install
Unlike current xkbcommon, X11’s xkbcomp allows to remove entries in
the modifiers’ map using “modifier_map None { … }”.
“None” is translated to the special value “XkbNoModifier” defined in
“X11/extensions/XKB.h”. Then it relies on the fact that in "CopyModMapDef",
the following code:
1U << entry->modifier
ends up being zero when “entry->modifier” is “XkbNoModifier” (i.e. 0xFF).
Indeed, it relies on the overflow behaviour of the left shift, which in
practice resolves to use only the 5 low bits of the shift amount, i.e.
0x1F here. Then the result of “1U << 0xFF” is cast to “char”, i.e. 0.
This is a good trick but too magical, so in libxkbcommon we will use
an explicit test against our new constant XKB_MOD_NONE.
- Add table of contents
- Add terminology section
- (WIP) Add Introduction to the format
- Improve the keycode section
- Improve the interpret section
- Add guide to create and use modifiers
- (WIP) Add actions documentation
- Add cross-references
- Add keysyms header to documentation
`_MSC_VER` is specific to MSVC, but there can be other compilers targeting
windows. Hopefully they do define `_WIN32`, so let's use that.
Refs: https://github.com/xkbcommon/libxkbcommon/issues/305
Signed-off-by: Ran Benita <ran@unusedvar.com>
Meson complains; it's probably not that important anymore when using the
`-Db_sanitize` options.
meson.build:36: WARNING: Consider using the built-in option for sanitizers instead of using "-fsanitize-undefined-trap-on-error".
Signed-off-by: Ran Benita <ran@unusedvar.com>
A test case failure usually also triggers valgrind leaks, sifting through those
to find the actual test failure is painful. So let's separate the tests and run
them separately.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We need to request the lower version of the interface versions we
support and the server supports, not the higher version.
Using the higher version caused crashes due to unbound callbacks on
GNOME, which supports a higher version of `xdg_wm_base`.
This entry maps a non existing special keysym 0x20a9.
The correct mapping for XKB_KEY_Korean_Won (0x0eff) already exists.
Signed-off-by: Ran Benita <ran@unusedvar.com>
Not sure what it's doing here, but converting "€" to a keysym
doesn't work with this entry. 0x13a4 doesn't appear in
xkbcommon-keysyms.h. 0x20ac is the keysym documented in the
header (and it's the last entry in the table).
It's been in the table since it was introduced in e0524296d2
("Add API for getting unicode representation of a keysym").
Co-authored-by: Simon Ser <contact@emersion.fr>
lokid and hikid actually stores the sibling to current node, which
should not be cleared when override. This would break the sequence with
a common prefix when override another.
Fix#286
Signed-off-by: Weng Xuetian <wengxt@gmail.com>
From the documentation:
> It does not clean up parser state, it cleans up memory allocated by the library
> itself. It is a cleanup function for the XML library. It tries to reclaim all
> related global memory allocated for the library processing. [...]
> One should call xmlCleanupParser() only when the process has finished using the library.
http://xmlsoft.org/html/libxml-parser.html#xmlCleanupParser
Since we're a library ourselves we cannot know if something else in the same
proces uses the parser, so we must not call this.
Reported-by: M Hickford
This makes it easier for contributors to check if their code runs correctly
without having to file a PR.
The Mac and Windows workflows are a bit more involved, so let's keep those on
pull requests only.
"main" is a bit non-descriptive, let's name them after the platforms we run them
on. Splitting them up allows us to be less selective on how we run the various
workflows, e.g. always running the linux one.
Ran Benita
Peter Hutterer
Pierre Le Marre
Ken Cunningham
Simon Ser
Ronan Pigott
Jan Alexander Steffens (heftig)
Sam Lantinga
Weng Xuetian
Mladen Milinkovic
M Hickford