There are a number of XKB requests needed to request all the information from
the X11 server. So far, the code was sending one request and waiting for the
reply. This commit starts batching the request so that we get multiple replies
with one round trip.
This removes three round trips.
Only the simple requests are converted. get_map() and get_names() use some
bitmasks that are needed for both the request and the reply. These will be dealt
with separately.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of asking for an atom name and waiting for the reply four times, this
now sends four GetAtomName requests and waits for all the replies at once. Thus,
this saves three round trips.
Signed-off-by: Uli Schlachter <psychon@znc.in>
On my system, calling xkb_x11_keymap_new_from_device() did 78 round trips to the
X11 server, which seems excessive. This commit brings this number down to about
9 to 10 round trips.
The existing functions adopt_atom() and adopt_atoms() guarantee that the atom
was adopted by the time they return. Thus, each call to these functions must do
a round-trip. However, none of the callers need this guarantee.
This commit makes "atom adopting" asynchronous: Only some time later is the atom
actually adopted. Until then, it is in some pending "limbo" state.
This actually fixes a TODO in the comments.
Fixes: https://github.com/xkbcommon/libxkbcommon/issues/216
Signed-off-by: Uli Schlachter <psychon@znc.in>
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 ] };
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>
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>
Before reading ~/.XCompose, try to read $XDG_CONFIG_HOME/XCompose
(falling back to ~/.config/XCompose).
This helps unclutter the home directory of users who want that.
Don't do the realloc dance, just asprintf to the buffer and move on. The check
is likely pointless anyway, if we run out of asprintf size, log_error will
probably blow up as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We only ever care about whether we error out or not, so let's wrap this into
something more sane.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that we're relying on various different include paths, let's log that ones
we use and the ones we failed to use.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This library is the replacement for clients parsing evdev.xml directly.
Instead, they should use the API here so that in the future we may even
be able to swap evdev.xml for a more suitable data format.
The library parses through evdev.xml (using libxml2) and - if requested -
through evdev.extras.xml as well. The merge approach is optimised for
the default case where we have a system-installed rules XML and another file in
$XDG_CONFIG_DIR that adds a few entries. We load the system file first, then
append any custom ones to that. It's not possible to overwrite the MLVO list
provided by the system files - if you want to do that, get the change upstream.
XML validation is handled through the DTD itself which means we only need to
check for a nonempty name, everything else the DTD validation should complain
about.
The logging system is effectively identical to xkbcommon.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Returns true on success or false on error _or_ truncation. Since truncation is
almost always an error anyway, we might as well make this easier to check.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the active set of modifiers doesn't match any explicit entry of the
key type, the resulting level is 0 (i.e. Level 1). Some key types don't
explicitly map Level 1, taking advantage of this fallback.
Previously, xkb_keymap_key_get_mods_for_level didn't consider this, and
only reported masks for explicit mappings. But this causes some glaring
omissions, like matching "a" in the "us" keymap returning not results.
Since every mask which isn't explicitly mapped falls back to 0, we can't
return the all. Almost always the best choice for this is the empty
mask, so return that, when applicable.
Fixes https://github.com/xkbcommon/libxkbcommon/issues/140.
Reported-by: https://github.com/AliKet
Signed-off-by: Ran Benita <ran@unusedvar.com>
The new API is useful to implement features like auto-type and
desktop automation. Since the inputs for these features is usually
specified in terms of the symbols that need to be typed, the
implementation needs to be able to invert the keycode->keysym
transformation and produce a sequence of keycodes that can be used
to type the requested character(s).
In order to support features like auto-type and UI automation, the
relevant tools need to be able to invert the keycode->keysym->text
transformation. In order to facilitate that, a new API was added.
It allows querying the keysyms that correspond to particular Unicode
codepoints. For all practical purposes, it can be thought of as an
inverse of xkb_keysym_to_utf32().
Only the input/output functions from <unistd.h> options are used, so
using <io.h> when building with MSVC should be enough. The inclusion
of the header in context-priv.c does not seem to be needed (tested
on GNU/Linux) and so it is removed.
Signed-off-by: Ran Benita <ran@unusedvar.com>
Detected by MSVC:
xkbcomp\xkbcomp.c(111): warning C4047: 'return': 'bool' differs in levels of indirection from 'void *'
Signed-off-by: Ran Benita <ran@unusedvar.com>
Don't use int which can have different size on different machines.
Also avoid some warnings from MSVC:
xkbcomp/parser.y(760): warning C4244: '=': conversion from 'int64_t' to 'int', possible loss of data
xkbcomp/parser.y(761): warning C4244: '=': conversion from 'int64_t' to 'int', possible loss of data
xkbcomp/parser.y(767): warning C4244: '=': conversion from 'int64_t' to 'int', possible loss of data
Signed-off-by: Ran Benita <ran@unusedvar.com>
This increases the size of the struct a bit but it's not very important.
Fixes these MSVC warnings:
src\scanner-utils.h(112): warning C4267: '+=': conversion from 'size_t' to 'unsigned int', possible loss of data
src\scanner-utils.h(147): warning C4267: '+=': conversion from 'size_t' to 'unsigned int', possible loss of data
Signed-off-by: Ran Benita <ran@unusedvar.com>
Previously we included it with an `-include` compiler directive. But
that's not portable. And it's better to be explicit anyway.
Every .c file should have `include "config.h"` first thing.
Signed-off-by: Ran Benita <ran@unusedvar.com>
Some environments (e.g. Windows + MSVC) do not provide asprintf() or
vasprintf(). This tries to detect their presence, and provides suitable
fallback implementations when not available.
Some environments (e.g. Windows + MSVC) do not provide strndup(), this
tries to detect its presence and provide a fallback implementation when
not available.
[ran: some tweaks]
This avoids the problem that MSVC does not provide strcasecmp() nor
strncasecmp(), and at the same time avoids potential problems due to
locale configuration by using istrcmp() and istrncmp() which are
already in the source tree and written to cover only ASCII.
This condition happens in xkeyboard-config keymaps and seems hard to
fix. Currently it incessantly spams people's logs who have no idea what
to do about it. So downgrade to "warning" level, so it doesn't show up
by default.
When working on keymaps, set `XKB_LOG_LEVEL=debug XKB_LOG_VERBOSITY=10`
to see all possible messages.
Refs https://github.com/xkbcommon/libxkbcommon/issues/111
Fixes https://github.com/xkbcommon/libxkbcommon/issues/128
Signed-off-by: Ran Benita <ran@unusedvar.com>
FindXkbFileInPath() opens the file so we're guaranteed that the file not only
exists, but that we can read it. Changing that would alter behavior so instead
let's just pass that file handle along and do the same for include files.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The majority use-case for extending XKB on a machine is to override one or a
few keys with custom keycodes, not to define whole layouts.
Previously, we relied on the rules file to be a single file, making it hard to
extend. libxkbcommon parses $XDG_CONFIG_HOME/xkb/ but that only works as long
as there is a rule that matches the user-specified RMLVO. This works for MLV
but not for options which don't have a wildcard defined. Users have to copy
the whole rules file and then work from there - not something easy to extend
and maintain.
This patch adds a new ! include directive to rules files that allows including
another file. The file path must be without quotes and may not start with the
literal "include". Two directives are supported, %H to $HOME and %S for the
system-installed rules directory (usually /usr/share/X11/xkb/rules).
A user would typically use a custom rules file like this:
! option = symbols
custom:foo = +custom(foo)
custom:bar = +custom(baz)
! include %S/evdev
Where the above defines the two options and then includes the system-installed
evdev rule. Since most current implementations default to loading the "evdev"
ruleset, it's best to name this $XDG_CONFIG_HOME/xkb/rules/evdev, but any
valid name is allowed.
The include functionally replaces the line with the content of the included
file which means the behavior of rules files is maintained. Specifically,
custom options must be defined before including another file because the first
match usually wins. In other words, the following ruleset will not assign
my_model as one would expect:
! include %S/evdev
! model = symbols
my_model = +custom(foo)
The default evdev ruleset has wildcards for model and those match before the
my_model is hit.
The actual resolved components need only be in one of the XKB lookup
directories, e.g. for the example above:
$ cat $XDG_CONFIG_HOME/xkb/symbols/custom
partial alphanumeric_keys
xkb_symbols "foo" {
key <TLDE> { [ VoidSymbol ] };
};
partial alphanumeric_keys
xkb_symbols "baz" {
key <AB01> { [ k, K ] };
};
This can then be loaded with the XKB option "custom:foo,custom:bar".
The use of "custom" is just as an example, there are no naming requirements
beyond avoiding already-used ones. Also note the bar/baz above - the option
names don't have to match the component names.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No functional changes but we'll need that same lookup in the rules file
include handling in a future patch.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This shouldn't be processed in the matcher itself, especially in the glorious
future when we can have nested matchers. Only handle this once in the caller
to the original parsed file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No functional changes, this is what the macro expanded to anyway. Prep work
for putting the scanner on the stack and removing it from the matcher struct.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
lowercase: LATIN SMALL LETTER SHARP S (U+00DF)
uppercase: LATIN CAPITAL LETTER SHARP S (U+1E9E)
The uppercase sharp s (XK_ssharp) is a relatively recent addition to unicode
but was added to the relevant keyboard layouts in xkeyboard-config-2.25
(d1411e5e95c)
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/144
Alas, the CapsLock behavior was broken on the finnish layout (maybe others).
This was due XConvertCase() never returning the uppercase characters.
Let's make this function return the right lower/upper symbols for the sharp s
and hope that the world won't get any worse because of it.
Corresponding Xlib issue:
https://gitlab.freedesktop.org/xorg/lib/libx11/issues/110
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In the AST, lists (e.g. the list of statements in a file) are kept in
singly-linked lists -- each AST node has a `next` pointer available for
this purpose.
Previously, a node was added to the list by starting from the head,
chasing to the last, and appending. So creating a list of length N would
take ~N^2/2 pointer dereferences.
Now, we always (temporarily) keep the last as well, so appending is O(1)
instead of O(N).
Given a keymap
xkb_keymap {
xkb_keycodes {
minimum = 8;
minimum = 8;
minimum = 8;
minimum = 8;
minimum = 8;
[... repeated N times ...]
};
xkb_types {};
xkb_compat {};
xkb_symbols {};
};
The compilation times are
N | Before | After
--------|----------|-------
10,000 | 0.407s | 0.006s
20,000 | 1.851s | 0.015s
30,000 | 5.737s | 0.021s
40,000 | 12.759s | 0.023s
50,000 | 21.489s | 0.035s
60,000 | 40.473s | 0.041s
70,000 | 53.336s | 0.039s
80,000 | 72.485s | 0.044s
90,000 | 94.703s | 0.048s
100,000 | 118.390s | 0.057s
Another option is to ditch the linked lists and use arrays instead. I
got it to work, but its more involved and allocation heavy so turns out
to be worse without further optimizations.
Signed-off-by: Ran Benita <ran@unusedvar.com>
Given
interpret ISO_Level3_Shift+AnyOf(all,extraneous) { ... };
Previously, extraneous (and further) was ignored. Now it's rejected.
Signed-off-by: Ran Benita <ran@unusedvar.com>
Given
augment virtual_modifiers NumLock,Alt,LevelThree
Previously it was expanded (directly in the parser) to
augment virtual_modifiers NumLock;
virtual_modifiers Alt;
virtual_modifiers LevelThree;
Now it expands to
augment virtual_modifiers NumLock;
augment virtual_modifiers Alt;
augment virtual_modifiers LevelThree;
Signed-off-by: Ran Benita <ran@unusedvar.com>
Fixup of ccab349 - unlike the commit message, hash a byte twice instead
of zero times, which is probably better. This is how it was before.
Signed-off-by: Ran Benita <ran@unusedvar.com>
FNV-1a instead of the djb2-like one from before.
Keep the unrolling since it seems quite beneficial, even though it loses
one byte if the length is odd...
Signed-off-by: Ran Benita <ran@unusedvar.com>
This requires (well, at least implemented by) casting away `const` which
is undefined behavior, and clang started to warn about it.
The micro optimization didn't save too many allocations, anyway.
Signed-off-by: Ran Benita <ran@unusedvar.com>
Use $XDG_CONFIG_HOME/xkb as the primary lookup path for XKB rules. Same
motivation as in 3a91788d92, however the XDG directories are more standard
and recommended these days than application-specific dotfiles.
The XDG spec says to fall back to $HOME/.config where XDG_CONFIG_HOME is not
set so we implement that behavior as well.
Fixes#112
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
E.g. when Mutter has CAP_SYS_NICE and thus secure_getenv returns NULL.
Fixes https://bugs.archlinux.org/task/64191
[ran: changed to ignore error]
Signed-off-by: Ran Benita <ran@unusedvar.com>
xkbcomp only accepts the "Level" prefix for a level name for levels 1 to
8, but the keymap dumping code added it always, e.g. "Level15".
The plain integer, e.g. "8", "15" is always accepted, so just use that.
Fixes https://github.com/xkbcommon/libxkbcommon/issues/113
Signed-off-by: Ran Benita <ran@unusedvar.com>
Reported-by: progandy
Previously, the default include path was XKB_CONFIG_ROOT:~/.xkb.
The ~/.xkb include path is intended to allow the local user to customize
their keymaps without having to modify system paths.
But usually, the user only wants to customize specific parts. When
XKB_CONFIG_ROOT is first, the user can only customize through the "entry
point" (the RMLVO). When ~/.xkb is first, the user can drop in a file
and it will override the system one.
The impetus for this change is the rules file. "evdev" is hard-coded
everywhere, so it not often not possible to change to something else.
And the rules files determines how the rest of the RMLVO is interpreted.
So, to enable customization, we have these options:
A: System includes user.
B: User includes system.
C: Library goes over both in one or the other order.
Option A is problematic due to backward compatibility and is also
unnatural.
Option B gives the user control and is backward compatible, so that's
what we choose. This is also how Compose files are handled, and that
seems to work fine in the wild.
Option C is actually less flexible than B, and more complicated.
(The rules file format doesn't have an include statement yet, but it's
planned).
Signed-off-by: Ran Benita <ran@unusedvar.com>
We don't need to determine the total number of bits set to determine if
exactly one is set.
Additionally, on x86_64 without any -march=* flag, __builtin_popcount
will get compiled to a function call to the compiler runtime (on gcc),
or a long sequence of bit operations (on clang).
Signed-off-by: Michael Forney <mforney@mforney.org>
xproto recently has been extended with 2 new keysyms:
XF86XK_MonBrightnessCycle
XF86XK_RotationLockToggle
This commit is the result of running "scripts/update-keysyms" on a system
with the updated xproto installed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Found by Oracle's Parfait 2.2 static analyzer:
Error: Buffer overrun
Read outside array bounds [read-outside-array-bounds] (CWE 125):
In array dereference of xkb_file_type_strings[type] with index type
Array size is 56 bytes, index <= 56
at line 734 of src/xkbcomp/ast-build.c in function 'xkb_file_type_to_string'.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Left shift of a negative integer. For some reason the protocol
representation here got really botched (in the spec it is just a nice
and simple INT16).
Signed-off-by: Ran Benita <ran234@gmail.com>
Don't try to divide through a signed char when indexing an array, lest
ye try to index off the start of it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The only time we could ever hit this was with count == 0, which seems
unnecessarily pedantic. But OK.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Every user of ExprReturnLhs goes on to unconditionally dereference the
field return, which can be NULL if xkb_intern_atom fails. Return false
if this is the case, so we fail safely.
testcase: splice geometry data into interp
Signed-off-by: Daniel Stone <daniels@collabora.com>
If we have an expression of the form 'l1' in an interp section, we
unconditionally try to dereference its args, even if it has none.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If the scanner indicates that we might have something which looks like a
map, but the parser in fact fails to create that map, we will try to
access the map regardless. Stop doing that.
testcase: 'xkb_keymap {' -> '#kb_keymap'
Signed-off-by: Daniel Stone <daniels@collabora.com>
Coverity complains that a 7-byte string may not be null-terminated when copied
into act->data (size 7). This is fine, make a note of it.
All the strings in xkeyboard-config only use 6 bytes + null terminator so this
won't be an issue. The server (the only user of these) uses an 8-byte array
and forcibly null-terminates the string, see XkbDDXPrivate().
Everything else treats it as byte-array size 7 anyway so whether it's
null-terminated doesn't matter.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Move the aliases copy to within the (num_key_aliases > 0) block.
Passing info->aliases into this fuction with invalid aliases will
cause log messages but num_key_aliases stays on 0. The key_aliases array
is never allocated and remains NULL. We then loop through the aliases, causing
a null-pointer dereference.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's a (theoretical?) path where we might end up strcpy() buf without ever
writing to it. This happens if the mask is nonzero but specifies a modifier
larger than the one in the xkb_mod_set.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The parser would enter an infinite loop if an unterminated keysym
literal occurs at EOF.
Found with the afl fuzzer.
Signed-off-by: Ran Benita <ran234@gmail.com>
xkb_geometry sections are ignored; previously the had done so by
returning NULL for the section's XkbFile, however some sections of the
code do not expect this. Instead, create an XkbFile for it, it will
never be processes and discarded later.
Caught with the afl fuzzer.
Signed-off-by: Ran Benita <ran234@gmail.com>
In the XKB format, floats and various keywords can only be used in the
xkb_geometry section. xkbcommon removed support xkb_geometry, but still
parses it for backward compatibility. As part of ignoring it, the float
AST node and various keywords were removed, and instead NULL was
returned by their parsing actions. However, the rest of the code does
not handle NULLs, and so when they appear crashes usually ensue.
To fix this, restore the float AST node and the ignored keywords. None
of the evaluating code expects them, so nice error are displayed.
Caught with the afl fuzzer.
Signed-off-by: Ran Benita <ran234@gmail.com>
The expression evaluator would go into an infinite recursion when
evaluating something like this as a boolean: `!True`. Instead of
recursing to just `True` and negating, it recursed to `!True` itself
again.
Bug inherited from xkbcomp.
Caught with the afl fuzzer.
Signed-off-by: Ran Benita <ran234@gmail.com>
The default fallback type uses
type->level_names = NULL
but the keymap-dump code was not checking this case.
Instead of adding more workarounds and possible bugs (e.g. previous
commit), let's just keep the number of level names separately. This has
the additional advantage retains extraneous level name if someone adds
them for some reason.
Signed-off-by: Ran Benita <ran234@gmail.com>
The buggy code assigned the number of levels based on the number of
level names in the definition, instead of the actual number of levels!
This would completely break type definitions which do not give names to
levels.
This was not noticed for so long because xkeyboard-config always gives
names to all levels.
This regressed in 61fed8dab9.
Reported-by: Gatis Paeglis <gatis.paeglis@qt.io>
Signed-off-by: Ran Benita <ran234@gmail.com>
These can be useful in some odd cases.
There is already an implementation (+ tests) for internal use, so all
that's needed is to export them.
If xkbcommon were to provide a way to convert a Unicode codepoint to a
keysym, this could have been implemented externally as follows:
uint32_t codepoint = xkb_keysym_to_utf32(keysym);
uint32_t upper_codepoint = my_unicode_library_to_upper(codepoint);
xkb_keysym_t upper_keysym = theoretical_xkb_keysym_from_utf32(upper_codepoint);
However keysym -> codepoint is not injective so such a function is not
possible strictly speaking.
Signed-off-by: Ran Benita <ran234@gmail.com>
The change in d44ba48 removed -I$(top_builddir)/src/xkbcomp, but this is
needed in order to find the generated parser.h file which is put in the
build dir.
I also added -I$(top_builddir)/src in order to match the meson behavior.
Fixes https://github.com/xkbcommon/libxkbcommon/issues/50
Signed-off-by: Ran Benita <ran234@gmail.com>
xproto recently has been extended with 4 new keysyms:
XF86XK_Keyboard
XF86XK_WWAN
XF86XK_RFKill
XF86XK_AudioPreset
This commit is the result of running "make update-keysyms" on a system
with the updated xproto installed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When we fall through to another label in a case, add an explicit comment
noting so, to quiet GCC 7's warnings.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The hit rate is high, but either the cache is slow or the function is
not fast enough -- the cache no longer holds its weight, leading only to
very modest improvements. If it's the former, it can definitely be
improved, the code is very dumb (though it worked just as well as any
other I tried back then). But instead, let's just kill it.
Signed-off-by: Ran Benita <ran234@gmail.com>
We currently use strcasecmp, which is locale-dependent. In particular,
one well-known surprise even if restricted just ASCII input is found in
the tr_TR (Turkish) locale, see e.g.
https://msdn.microsoft.com/en-us/library/ms973919.aspx#stringsinnet20_topic5
We have known to avoid locale-dependent functions before, but in this
case, we forgot.
Fix it by implementing our own simple ASCII-only strcasecmp/strncasecmp.
Might have been possible to use strcasecmp_l() with the C locale, but
went the easy route.
Side advantage is that even this non-optimized version is faster than
the optimized libc one (__strcasecmp_l_sse42) since it doesn't need to
do the locale stuff. xkb_keysym_from_name(), which uses strcasecmp
heavily, becomes faster, and so for example Compose file parsing, which
uses xkb_keysym_from_name() heavily, becomes ~20% faster.
Resolves https://github.com/xkbcommon/libxkbcommon/issues/42
Signed-off-by: Ran Benita <ran234@gmail.com>
The current functions dealing with consumed modifiers use the
traditional XKB definition of consumed modifiers (see description in the
added documentation). However, for several users of the library (e.g.
GTK) this definition is unsuitable or too eager. This is exacerbated by
some less-than-ideal xkeyboard-config type definitions (CTRL+ALT seems
to cause most grief...).
So, because we
- want to enable alternative interpretations, but
- don't want to expose too much internal details, and
- want to keep things simple for all library users,
we add a high-level "mode" parameter which selects the desired
interpretation. New ones can be added as long as they make some sense.
All of the old consumed-modifiers functions keep using the traditional
("XKB") mode. I mark xkb_state_mod_mask_remove_consumed() and as
deprecated without adding a *2 variant because I don't it is very useful
(or used) in practice.
Alternative modes are added in subsequent commits (this commit only adds
a mode for the existing behavior).
https://github.com/xkbcommon/libxkbcommon/issues/17
Signed-off-by: Ran Benita <ran234@gmail.com>
fileno() can fail, if called on e.g. fmemopen() FILEs which are not
backed by a file descriptor. This functions uses mmap to map the entire
file to memory, so using such FILEs will not work.
(There is actually no change of behavior here, since the following fstat
would have already failed with EBADF. But lets make it clear.)
Another possibility is to fall back to the !HAVE_MMAP case; but it
sounds like a better idea to leave it to the programmer to use the
new_from_string/new_from_buffer functions instead, instead of doing
double allocation behind their back.
Signed-off-by: Ran Benita <ran234@gmail.com>
xkb_keymap_key_by_name() allows finding a keycode from a given keyname and
is useful for generating keyboard events to use in regression tests
during CI
xkb_keymap_key_get_name() is the inverse of xkb_keymap_key_by_name()
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
[ran: some stylistic tweaks + another test case]
Signed-off-by: Ran Benita <ran234@gmail.com>
map_file() uses PROT_READ, so const seems fitting; however unmap_file
calls munmap/free, which do not take const, so an UNCONSTIFY is needed.
To avoid the UNCONSTIFY hack, which is likely undefined behavior or some
such, just remove the const.
Signed-off-by: Ran Benita <ran234@gmail.com>
Uli Schlachter
Pierre Le Marre
Peter Hutterer
Ran Benita
hhb
Emmanuel Gil Peyrot
Jaroslaw Kubik
Adrian Perez de Castro
Jan Alexander Steffens (heftig)
Michael Forney
Konstantin Kharlamov
Hans de Goede
Alan Coopersmith
Ran Benita
Daniel Stone
Matt Whitlock
Mike Blumenkrantz
Michael Vogt