| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
Support for version checks in `find_program()`.
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.
|
|
|
|
| |
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
| |
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
| |
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Ref: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/commit/914d8f5e0f469cd0416364dd008e9eea752bf703
Ref: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/commit/a839f0c7fc5596d10e786394d3b0953eb8a1731b
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
|
|
|
|
| |
`_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>
|
|
|
|
|
|
|
|
|
| |
Same numeric value for both and the Serbian one has been listed as deprecated
for decades.
See https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/69#note_1843415
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
| |
This allows xkbcommon to be used as a subproject.
Signed-off-by: Simon Ser <contact@emersion.fr>
|
|
|
|
| |
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
| |
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
| |
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
|
|
|
| |
Add a common page for the concept and link to there from the relevant
functions.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
| |
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
|
|
| |
It's redundant with the pull request run.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
|
|
|
|
|
| |
This flag is useful for clients that may have relatively benign capabilities
set, like CAP_SYS_NICE, that also want to use the xkb configuration from the
environment and user configs in XDG_CONFIG_HOME.
Fixes: https://github.com/xkbcommon/libxkbcommon/issues/308
Fixes: https://github.com/xkbcommon/libxkbcommon/issues/129
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>
|
|
|
|
|
|
| |
Node 12 is deprecated so let's bump the actions to newer versions that
use Node 16. See
https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/
|
|
|
|
| |
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
| |
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
| |
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
|
|
| |
This makes debugging a lot easier than having to reproduce locally.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
| |
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`.
|
|
|
|
| |
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These ended up being mapping in the 0x100xxxx Unicode range, which are
handled automatically ; these special keysyms don't exist (except for
EuroSign).
#define XKB_KEY_EcuSign 0x10020a0 /* U+20A0 EURO-CURRENCY SIGN */
#define XKB_KEY_ColonSign 0x10020a1 /* U+20A1 COLON SIGN */
#define XKB_KEY_CruzeiroSign 0x10020a2 /* U+20A2 CRUZEIRO SIGN */
#define XKB_KEY_FFrancSign 0x10020a3 /* U+20A3 FRENCH FRANC SIGN */
#define XKB_KEY_LiraSign 0x10020a4 /* U+20A4 LIRA SIGN */
#define XKB_KEY_MillSign 0x10020a5 /* U+20A5 MILL SIGN */
#define XKB_KEY_NairaSign 0x10020a6 /* U+20A6 NAIRA SIGN */
#define XKB_KEY_PesetaSign 0x10020a7 /* U+20A7 PESETA SIGN */
#define XKB_KEY_RupeeSign 0x10020a8 /* U+20A8 RUPEE SIGN */
#define XKB_KEY_WonSign 0x10020a9 /* U+20A9 WON SIGN */
#define XKB_KEY_NewSheqelSign 0x10020aa /* U+20AA NEW SHEQEL SIGN */
#define XKB_KEY_DongSign 0x10020ab /* U+20AB DONG SIGN */
#define XKB_KEY_EuroSign 0x20ac /* U+20AC EURO SIGN */
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
|
|
|
| |
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 e0524296d2e0
("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>
|
|
|
|
| |
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
|
|
|
|
| |
Particularly `eof()` in mingw-w64.
Fixes: https://github.com/xkbcommon/libxkbcommon/pull/285
Reported-by: Marko Lindqvist
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
| |
|
|
|
|
| |
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
| |
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
|
| |
See efa99624320f54e6e1ff24e4c4b1fcecdfba43d5
|
|
|
|
| |
omitted (#266)
|
|
|
|
| |
If the XML file is somehow off, don't load entries that are against the spec.
|
|
|
|
|
| |
We already do so for the non-successful cases, let's do this here too so we know
whether it was a signal or a normal exit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Co-authored-by: Ran Benita <ran@unusedvar.com>
|
| |
|
|
|
|
|
|
| |
this is mainly useful for multilib, but may be useful for other users as well
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
|