In `parser.y`, a numeric keysym is parsed by formatting it in its
hexadecimal form then parsed as a keysym name. This is convoluted.
Fixed by checking directly the upper bound.
When parsing hexadecimal keysym using `xkb_keysym_from_name`,
the result is limited by `parse_keysym_hex` to 0xffffffff, but the
maximum keysym is XKB_MAX_KEYSYM, i.e. 0x1fffffff.
Fixed by adding an upper bound.
Keysyms are 32-bit integers with the 3 most significant bits always set
to zero. See: Appendix A “KEYSYM Encoding” of the X Window System
Protocol at https://www.x.org/releases/current/doc/xproto/x11protocol.html#keysym_encoding.
Add a new constants XKB_KEYSYM_MIN and XKB_KEYSYM_MAX to make the
interval of valid keysyms more obvious in the code.
Doxygen 1.9.7 breaks our urls, see issue #347. Let's put a check for the
doxygen version into our CI build so that if our base distro updates beyond
that, the CI fails and we know we have to build doxygen from scratch or
update to some other version that's supported.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Upload the doxygen output as artifact from the linux build and use that from
the pages job where we combine the static website with our newly build HTML
docs. The GitHub actions/download-artefact doesn't work across workflows so
we use the other popular one that can do this. The rest of the job is
basically copy/paste from the "Static HTML" example GitHub provides.
To make this useful as drop-in replacement, replace the one fixed link to the
API docs a relative one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The script `ensure-stable-doc-urls.py` relies on the Doxygen output files
names. These may change between Doxygen versions, although the Doxygen
developers intend stability.
Since the script is useful mainly for the online documentation of
xkbcommon, make the target `doc-cool-uris` optional.
The test `test_from_locale` fails when there is a user-defined compose
file, e.g. ~/.XCompose.
Indeed, the function `xkb_compose_table_new_from_locale` use various
environment variables to determine the location of the compose file.
Ensure no environment variables but the required ones are set, in order
to have robust tests.
Currently there is no interactive tool allowing to set the include
paths of the context, such as in "compile-keymap". Note that only
"interactive-evdev" makes sense, because it does not rely on a
compositor.
Add --include and --include-defaults to "interactive-evdev" tool.
The code is adapted from "compile-keymap".
- Force Doxygen version 1.9.6, because 1.9.7 breaks our doc cool URIs,
i.e. our system that maintain stable doc pages via redirection.
Associated issue in Doxygen:
https://github.com/doxygen/doxygen/issues/10146
- Install graphviz to build the .dot files.
In commit 1638409b22, the number of
compose nodes was limited to 65535 to enable "future optimizations",
which apparently means slightly reduced memory usage due to fitting in
a uint16_t. At this time, it was mentioned that the author was not
aware of "any compose files which come close".
However, I'm one of the users that actually do require a larger number
of nodes for their compose file. Thus, use a uint32_t again and raise
the limit significantly.
Doc URLs may change with time because they depend on Doxygen machinery.
This is unfortunate because it is good practice to keep valid URLs
(see: https://www.w3.org/Provider/Style/URI.html).
I could not find a built-in solution in Doxygen, so the solution proposed
here is to maintain a registry of all URLs and manage legacy URLs as
redirections to their canonical page.
This commit adds a registry of URLs that has three functions:
- Check no previous URL is now invalid.
- Add aliases for moved pages.
- Generate redirection pages for aliases. The redirection works with
a simple <meta http-equiv="refresh"> HTML tag. See:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta#http-equiv
This commit also initialize the URLs registry with current pages and some
redirections needed after recent documentation refactoring.
Finally, the CI is updated to catch any change that invalidate previous
URLs.
There is no feedback that they are both replaced with default values.
Fix it by adding a warning informing about missing layout and show the
defaults for both.
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>
Pierre Le Marre
Peter Hutterer
Ran Benita
alois31
Ken Cunningham
Simon Ser
Ronan Pigott