With Dan Nicholson's permission (via email), update his copyright and
license statements to the standard X.Org boilerplate MIT license, as
both myself and Ran have been using.
Clean up my copyright declarations (in some cases to correct ownership),
and add copyright/license statements from myself and/or Ran where
appropriate.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This is not something I do often, but I have good reason here ...
utils.h has been totally rewritten since import, and now contains no
original DEC content. Everything in here has been added by Ran, and I
do not believe that any lingering content from previous iterations is
substantial enough as to be copyrightable.
Replace DEC's copyright (and license with hostile advertising clause)
with Ran's boilerplate copyright and license statement.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
As there is currently no stable release of xkbcommon, other projects might
want to include a copy of the keysyms so they can be used even though
libxkbcommon may not be available on the machine. However, if xkbcommon.h
is still included, conflicts will occur. Hence, to avoid nasty hacks,
simply include a header protection in xkbcommon upstream.
[daniels: Added protection to Makefile.am's update-keysyms, as well as
XKB_KEY_NoSymbol, and a comment noting that it shouldn't be
updated directly.]
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Before:
text data bss dec hex filename
234422 11288 2304 248014 3c8ce obj-amd64/.libs/libxkbcommon.so.0.0.0
After:
text data bss dec hex filename
240694 5016 2304 248014 3c8ce obj-amd64/.libs/libxkbcommon.so.0.0.0
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
In file included from external/collabora/libxkbcommon/src/xkb-priv.h:87,
from external/collabora/libxkbcommon/src/xkbcomp/xkbcomp.h:30,
from external/collabora/libxkbcommon/src/xkbcomp/xkbcomp-priv.h:30,
from external/collabora/libxkbcommon/src/xkbcomp/action.h:30,
from external/collabora/libxkbcommon/src/xkbcomp/action.c:27:
external/collabora/libxkbcommon/xkbcommon/xkbcommon.h:279: error: expected declaration specifiers or '...' before 'va_list'
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Squashed from commits by Helio Chissini de Castro
<helio.chissini.de.castro@collabora.co.uk> and Pekka Paalanen
<ppaalanen@gmail.com>.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
We didn't do anything with ISO_Lock, ActionMessage, RedirectKey, and the
device-specifying variants of the pointer actions, so remove those.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
There's no noticeable speed difference, but I think it's nicer and more
explicit than the previous code. Some people just don't like goto,
though..
Signed-off-by: Ran Benita <ran234@gmail.com>
We move the LookupEntry struct from expr.h to text.h, along with most of
the lookup tables. This makes them available everywhere.
Looking up a value in the LookupEntry format is slower than direct index
mapping, but it allows multiple names per value (with the canonical one
being first) and "all"- and "none"-type masks. These functions are not
used anywhere efficiency matters.
Signed-off-by: Ran Benita <ran234@gmail.com>
These were kept as atoms, but since the keymap was exposed in the API,
we converted them to strings; no the keymap is no longer exposed, so we
can go back to atoms. They make the keymap smaller (at least on 64-bit
machines) and the comparisons faster.
Signed-off-by: Ran Benita <ran234@gmail.com>
Almost all callers do xkb_atom_intern on the currently returned string,
while ResolveString converts the atom to the string to begin with...
uselss double work.
Signed-off-by: Ran Benita <ran234@gmail.com>
This will only lookup the string and return the atom if found; it will
not intern it if not. This is useful when e.g. getting a string from the
user (which may be arbitrary) and comparing against atoms.
Signed-off-by: Ran Benita <ran234@gmail.com>
There are two ways to separate multiple files in XKB include statements:
'+' will cause the later file to override the first in case of conflict,
while '|' will cause it augment it (this is done by xkbcomp). '!' is
unrelated here.
Since '|' is practically never used, this wasn't noticed.
In the modified test, the '|some_compat' previously was just ignored.
Signed-off-by: Ran Benita <ran234@gmail.com>
The format of the include statment is not explained anywhere, the code
is confusing and the comments misleading. Try to explain it better.
Signed-off-by: Ran Benita <ran234@gmail.com>
Avoids a warning, from xkeyboard-config:
commit 6676053f2c93596c2aaa9905151a5c76355a1540
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Jun 29 09:53:45 2012 +1000
symbols: keypad can only have one default section
Warning: Multiple default components in keypad
Using x11, ignoring pointerkeys
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Ran Benita <ran234@gmail.com>
For some reason this piece of code wasn't copied from xkbcomp, which
causes all of the warnings like these:
Warning: No map in include statement, but "pc" contains several; Using first defined map, "pc105"
Signed-off-by: Ran Benita <ran234@gmail.com>
This way the test logs have all the information, but we don't get eye
bleed every time we run them manually. One can always use
TESTS_ENVIRONMENT (we correctly use AM_TESTS_ENVIRONMENT now), or set
the envvars from the shell.
Signed-off-by: Ran Benita <ran234@gmail.com>
Now that we don't use syslog, "level" does sound more commonplace. We
should change it while there is still nobody using it.
Also leave some space between the integers of the xkb_log_level enum
values, if we ever need to shove more in between.
Signed-off-by: Ran Benita <ran234@gmail.com>
The implementation of changing the default properties of actions, e.g. a
statements such as (from test/data/compat/basic):
setMods.clearLocks= True;
latchMods.clearLocks= True;
latchMods.latchToLock= True;
works by keeping a list of ActionInfo's, each containing the neccesary
info from each statement, and then when some action comes up (e.g. in an
interpret statment) it goes through the list, and applies the relevent
ActionInfo's to the newly-constructed xkb_action.
Instead of doing this, we add a struct ActionsInfo, which contains an
array of xkb_actions, one for each type. When a default changing
statement appears, we change the action in the array; when a new action
comes up, we just copy from the array. This is simpler to figure out,
and pretty straightforward.
Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone
David Herrmann
Helio Chissini de Castro
Pekka Paalanen
Ran Benita