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>
These scripts generate source code that is committed to git and hence do
not really belong in the build system. A maintainer runs them as needed.
Signed-off-by: Ran Benita <ran234@gmail.com>
A bit more manageable this way, and the other part of the target is
already using python.
The output is the same, except I removed the reference to Makefile.am.
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>
Can happen in cases like:
- There was an error between the error check and the call.
- The internal poll() fails.
Signed-off-by: Ran Benita <ran234@gmail.com>
The enum seems large, and we don't handle all of the values in it.
Previously if we got an unrecognized SHM format we would use an
uninitialized `stride`.
Signed-off-by: Ran Benita <ran234@gmail.com>
Mutter only implements v6 now, and Weston also implements that. Port
interactive-wayland to this so people can keep on using it.
Signed-off-by: Daniel Stone <daniels@collabora.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>
See the NOTES section of getenv(3). Somewhat obscure but it doesn't hurt
to reassure the readers who know about this.
Signed-off-by: Ran Benita <ran234@gmail.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>
In particular, highlight the use of configure flags to control locating
X11 keyboard stuff when building for Wayland.
Of particular note, if the locale root is not specified, then xkbcommon
will look for them under $prefix (i.e. /usr/local/share/X11/locale).
But unless the user has specifically installed them there, it is better
to look in the standard system location, /usr/share/X11/locale.
Otherwise, xkbcommon will error when it can't find them, e.g.:
xkbcommon: ERROR: ~/.XCompose:4:9: failed to expand %L to the locale Compose file
xkbcommon: ERROR: ~/.XCompose:4:12: unterminated string literal
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
Otherwise it can segfault e.g. running ./compose inside the bench
directory.
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Naman Dixit
Hans de Goede
Daniel Stone
Bryce Harrington
Bryce Harrington