The ComputeEffectiveMap function is only called from keytypes.c, with
the last argument NULL, so we can move it there and remove some code.
The function XkbcVirtualModsToRealMods, of which the above is the only
user, is already implemented more simply in compat.c, so make this one
non-static and use it. This leaves src/xkb.c empty, so remove it.
Signed-off-by: Ran Benita <ran234@gmail.com>
commit 46441b1184 removed this from the
public API, and we don't need it internally. So send it to the archives.
Signed-off-by: Ran Benita <ran234@gmail.com>
To quote the spec:
XkbSI_AllOf
All of the bits that are on in mods must be set, but others may be
set as well.
Here "mods" refers to interp->mods. This matches xserver/libX11.
Signed-off-by: Ran Benita <ran234@gmail.com>
It doesn't play well with multiple keysyms per level right now. But
that's OK, because no-one really uses them.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Readd the component names to the keymap->names struct. This is used when
printing the component, e.g.
xkb_keymap {
xkb_keycodes "evdev+aliases(qwerty)" {
instead of
xkb_keymap {
xkb_keycodes {
This makes diffing against xkbcomp $DISPLAY a bit easier and is kind of
useful anyway.
Signed-off-by: Ran Benita <ran234@gmail.com>
Evidently good to have on its own, but also fixes a regression from
xkbcomp where we'd identify implicitly-typed Cyrillic keys as TWO_LEVEL
rather than ALPHABETIC.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The code used to match a keysym to a keycode (see added comment)
differed in behavior from xkbcomp, always taking the first key it found.
This caused some incorrect interpretation of the xkeyboard-config data,
for example the one corrected in dump.data (see the diff): since the
de-neo layout sets the both_capslock option, the Left Shift key (LFSH)
has the Caps_Lock keysym in group 4 level 2; now since
keycode(Left Shift) = 50 < keycode(Caps Lock) = 64
the Left Shift one was picked, instead of the Caps Lock one which is
group 1 level 1. The correct behavior is to pick according to group,
level, keycode.
Signed-off-by: Ran Benita <ran234@gmail.com>
Since BindIndicators was only ever called immediately after
CopyIndicatorMapDefs, move it up in the file and turn it into a static
function, which avoids the need to ever pass the unbound LEDs around.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
When we merge two KeyInfo's (belonging to the same keycode), we may take
a shortcut from copying if we see that the merged keys will be exactly
like those in one of the two KeyInfo's. In the case where we take the
symbols from the KeyInfo we are *not* merging into, we need to copy
the three arrays:
syms[group], symsMapNumEntries[group], symsMapIndex[group]
The code currently only copies the first one, so if there's a merge
conflict some levels may seem to disappear (i.e. have a NoSymbol
keysym).
This fixes the failing test added in c8d6bba.
Signed-off-by: Ran Benita <ran234@gmail.com>
This was broken by commit 18d331b86b
(where only the first option out of a comma-separated string was
matched). Do it correctly this time and add a test.
Signed-off-by: Ran Benita <ran234@gmail.com>
This commit fixes the incorrect current behavior, where at the end of the
following key sequence
Left Shift down, Right Shift down, Left Shift up
the Shift modifier is cleared.
Clearly the code is not as nice as before, but it seems like some count
of the depressed modifiers must be kept.
The code is lifted mostly as is from xkbActions.c. [ There they also
assign to setMods and clearMods each time and not OR it. I assume its
correct, although I wouldn't have guessed... ]
Signed-off-by: Ran Benita <ran234@gmail.com>
This commit removes the ability to specify a keymap *in a rules file*,
e.g. in /usr/share/X11/xkb/rules/evdev or somesuch. This is unused in
xkeyboard-data, and the current code has never even supported it,
because xkb_map_new_from_kccgst (which is no longer exposed in the API)
checks to see that one of the usual components (e.g. symbols, types, ..)
has been filled, while the rules parser, on the other hand, doesn't
allow to specify a keymap and other stuff at the same time.
( The idea was to remove xkb_map_new_from_kccgst entirely, but it's used
by a test so it can stay. )
tl;dr: dead code. Of course passing a keymap file to
xkb_map_new_from_file still works.
Signed-off-by: Ran Benita <ran234@gmail.com>
compile_keymap can only be passes a single keymap file now, from all
code paths leading to it. So this function doesn't do anything.
The remaining check is performed inside CompileKeymap, so we can remove
it as well; compile_keymap doesn't do much now.
Signed-off-by: Ran Benita <ran234@gmail.com>
It seems like at some point it was needed to break the abstraction and
perform this piece of code in the context above CompileCompatMap. The
extra argument and the typedef look strange now, and doesn't seem to be
needed any more, so move them back.
Signed-off-by: Ran Benita <ran234@gmail.com>
enums are nice for some type safety and readability. This one also
removes the distinction between file type mask / file type index and
some naming consistency.
Signed-off-by: Ran Benita <ran234@gmail.com>
If we've only derived that a key should repeat, rather than had it
explicitly specified, don't set the explicit member. Fixes the dump
test.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
An entry for a type will only get marked as active if a virtual modifier
can be directly mapped to it, and not if an action indirectly leads to
it (e.g. LevelThree). We don't really need this test since entries which
can never be triggered ... won't be triggered.
The entire map->active thing should probably just go away.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Our early exit in ApplyInterpsToKey meant we weren't hitting the code
that's supposed to set a sensible default autorepeat value for most
keys.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
For the darray we need to specify the explicit struct xkb_filter type
instead of void*, so we move the definition of struct xkb_state into
state.c thus making it opaque even from the rest of the files. It has
enough getters to get going and is otherwise good style.
Signed-off-by: Ran Benita <ran234@gmail.com>
The arrays found in KeyInfo are by far the most complicated, so this is
taken one member at a time so as not to break anything.
Signed-off-by: Ran Benita <ran234@gmail.com>
- Make darray_free also initialize the array back to an empty state, and
stop worrying about it everywhere.
- Add darray_mem, to access the underlying memory, which we do manually
now using &darray_item(arr, 0). This makes a bit more clear when we
actually mean to take the address of a specific item.
- Add darray_copy, to make a deep copy of a darray.
- Add darray_same, to test whether two darrays have the same underlying
memory (e.g. if the struct itself was value copied). This should used
where previously two arrays were compared for pointer equality.
Signed-off-by: Ran Benita <ran234@gmail.com>
Here are some quick numbers from valgrind, running rulescomp only with a
simple, common "us,de" rule set:
before darray: cb047bb
total heap usage: 44,924 allocs, 44,924 frees, 3,162,342 bytes allocated
after darray: c87468e
total heap usage: 52,670 allocs, 52,670 frees, 2,844,517 bytes allocated
tweaking specific inital allocation sizes:
total heap usage: 52,652 allocs, 52,652 frees, 2,841,814 bytes allocated
changing initial alloc = 2 globally
total heap usage: 47,802 allocs, 47,802 frees, 2,833,614 bytes allocated
changing initial alloc = 3 globally
total heap usage: 47,346 allocs, 47,346 frees, 3,307,110 bytes allocated
changing initial alloc = 4 globally
total heap usage: 44,643 allocs, 44,643 frees, 2,853,646 bytes allocated
[ Changing the geometric progression constant from 2 only made things
worse. I tried the golden ratio - not so golden :) ]
The last one is obviously the best, so it was chosen, with the specific
tweaks thrown in as well (these were there before but don't make much
difference). Overall it seems to do better than the previous manual
allocations which is a bit surprising.
Signed-off-by: Ran Benita <ran234@gmail.com>
These were made const when the structs were exposed in the API. Now they
are private and we shouldn't mess around with the UNCONSTIFY business.
Signed-off-by: Ran Benita <ran234@gmail.com>
This avoids a couple of special cases in the code, and is more
consistent. Since anyone who includes xkbcommon.h also gets
xkbcommon-keysyms.h, and anyone who include xkbcommon-keysyms.h would
want NoSymbol anyway, there's no down side.
Signed-off-by: Ran Benita <ran234@gmail.com>
This code uses a table and code derived from
http://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c
The added API calls are:
xkb_keysym_to_utf32
xkb_keysym_to_utf8
[daniels: Changed API to be more in line with keysym_get_name, added
test, changed formatting to 4-space.]
If we can merge cleanly (i.e. use the entirety of one entry rather than
having to go level by level), then just reuse the existing symbols array
and skip the entire merge process.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
A symbols file may contain a global, non key specific setting for
the group out-of-range handling method (wrap, clamp, redirect). Only
that:
* Its parsed and kept in the SymbolsInfo, but is not otherwise used in
any way (it's the same in the real xkbcomp).
* It's not used in any of xkeyboard-config files.
* It's not mentioned in the xkb specs (only the per-key ones).
* It doesn't make much sense anyway.
So remove the struct field, and emit an "unsupported, ignored" warning.
We don't increment the error count because of it, just continue (the
radio group warning just below is changed to do the same - there's no
reason to possibly abort the entire thing for it).
Signed-off-by: Ran Benita <ran234@gmail.com>
Conflicts:
src/xkbcomp/symbols.c
Instead of using NoSymbol in the map, we use num_syms == 0 to signify
the non-presence of a symbol. So instead of adding NoSymbol mappings
to the list regardless, detect them and set num_syms == 0.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The failure mode here is a little irritating:
- server loads map with ISO_Lock action
- server dumps keymap to string, including:
interpret ISO_Lock+AnyOfOrAll(None) {
action= NoAction();
};
as we don't (yet) print ISO_Lock actions
- client parses keymap from string
- client dumps keymap to string, including:
interpret ISO_Lock+AnyOfOrAll(None) {
};
- this results in a syntax error
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Some actions could also take relative rather than absolute parameters,
so they really needed to be signed instead of explicitly unsigned.
Oops.
Fixes, e.g., action= MovePtr(x=-1,y=+1), which was reported as
(x=+65535,y=+1).
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Currently, if you pass in an rmlvo with an empty string for layout or
variant, it would not match layout and variant rules even with
wildcards. But if the rules file had set an appropriate default, and someone
passes in the empty string, than he should get the default.
NULL in this case signifies not wanting to match against the layout or
variant at all, and so the rule should still fail to match NULLs.
Signed-off-by: Ran Benita <ran234@gmail.com>
Really all we need from this file is a way to get xkb_component_names
from an xkb_rule_names, which is now the only thing being exposed. This
should allow for some much needed refactoring of this code.
Since this is only used by xkbcomp.c and uses xkbcomp functions, also
move rules.{c,h} under the xkbcomp dir.
Signed-off-by: Ran Benita <ran234@gmail.com>
i.e. xkb_map_new_from_file. The reason is that flex only works with
FILE's, so we must use fdopen on the file descriptor; but to avoid a
memory leak, we must also fclose() it, which, in turn, closes the file
descriptor itself.
Either way is not acceptable, so we can either:
* dup() the fd and use fdopen on that, or
* have the user call fdopen on his own, and accept a FILE* instead of an
fd.
The second one seems better, and is standard C, so why not. We must add
stdio.h to xkbcommon.h though, which is regrettable, but not a big deal.
Signed-off-by: Ran Benita <ran234@gmail.com>
This partly reverts commit 8feba630fa.
This seems to fix valgrind errors:
==9581== Invalid read of size 4
==9581== at 0x4E50928: MergeKeyGroups (symbols.c:544)
==9581== by 0x4E510F3: MergeKeys (symbols.c:644)
==9581== by 0x4E514C6: AddKeySymbols (symbols.c:722)
==9581== by 0x4E51A3F: MergeIncludedSymbols (symbols.c:854)
==9581== by 0x4E51E97: HandleIncludeSymbols (symbols.c:952)
==9581== by 0x4E53D75: HandleSymbolsFile (symbols.c:1619)
==9581== by 0x4E55A0B: CompileSymbols (symbols.c:2187)
==9581== by 0x4E4056C: CompileKeymap (keymap.c:160)
==9581== by 0x4E56953: compile_keymap (xkbcomp.c:149)
==9581== by 0x4E56AC5: xkb_map_new_from_kccgst (xkbcomp.c:195)
==9581== by 0x4009D7: test_names (namescomp.c:56)
==9581== by 0x400A55: main (namescomp.c:75)
==9581== Address 0x5729b04 is 0 bytes after a block of size 4 alloc'd
==9581== at 0x4C29024: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9581== by 0x4E5C37B: recalloc (utils.c:41)
==9581== by 0x4E4FF50: ResizeKeyGroup (symbols.c:356)
==9581== by 0x4E5229E: AddSymbolsToKey (symbols.c:1058)
==9581== by 0x4E52ABB: SetSymbolsField (symbols.c:1214)
==9581== by 0x4E536C7: HandleSymbolsBody (symbols.c:1481)
==9581== by 0x4E53A63: HandleSymbolsDef (symbols.c:1543)
==9581== by 0x4E53DAD: HandleSymbolsFile (symbols.c:1623)
==9581== by 0x4E51CA4: HandleIncludeSymbols (symbols.c:909)
==9581== by 0x4E53D75: HandleSymbolsFile (symbols.c:1619)
==9581== by 0x4E51E74: HandleIncludeSymbols (symbols.c:951)
==9581== by 0x4E53D75: HandleSymbolsFile (symbols.c:1619)
Signed-off-by: Ran Benita <ran234@gmail.com>
Still keep things as 'ctx' internally so we don't have to worry about
typing it too often, but rename the user-visible API back as it was
kinda ugly.
This partially reverts e7bb1e5f.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
It was a pretty pointless check. Also sanitise the _x11 variant to
actually do what it says on the box.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
These are two aggregate file types which are not used anywhere. We
maintain useful-enough backward compatibility in the parser, by treating
them as xkb_keymap. The keymap type allows for all types of components,
so they will still compile fine if they ever come up.
Signed-off-by: Ran Benita <ran234@gmail.com>
(This breaks the API.)
"context" is really annoying to type all the time (and we're going to
type it a lot more :). "ctx" is clear, concise and common in many other
libraries. Use it!
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Fix for xkb -> keymap change.]
Each context gets its own table, i.e. interning a string in one context
does not affect any other context.
The existing xkb_atom_* functions are turned into wrappers around a new
standalone atom_table object.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb -> keymap.]
In preparation of contextualizing atom handling.
Since we touch every function call, we also rename the function to
xkb_atom_strdup to match xkb_atom_intern, and be more descriptive.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb -> keymap.]
In preparation of contextualizing the atom table.
Since we touch every function call, also rename the function to
xkb_atom_intern, to match better with the rest (which will also be
renamed).
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Fixed for 'xkb' -> 'keymap'.]
Currently the IDs are assigned from a static variable inside
CreateXKBFile. This can lead to some unpleasantness with threads, so
maintain the counter in the context instead.
Signed-off-by: Ran Benita <ran234@gmail.com>
We will need the context to remove some global state.
Also make the Parse* function just return bool while wer'e at it.
Signed-off-by: Ran Benita <ran234@gmail.com>
Change them to refer to the string representation of the keysym's name
as a name rather than a string, since we want to add API to get the
Unicode printable representation as well.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Two new calls allow users to test the exact modifier state, including
verifying that no other modifiers but the ones you wanted are down.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Make the files in the src/* directory use their own header or a
consilidated private header. This makes the file dependencies clearer.
Also drop the pointless "xkb" file name prefix, add split a few
declarations to their own files (atom.h and text.h).
Signed-off-by: Ran Benita <ran234@gmail.com>
The include dependencies were quite convoluted, where you change the
order and get a ton of errors. Instead, change one file to act as the
internal interface for the xkbcomp files, and make every file use it.
Also drop the pointless "xkb" prefix to file names.
Signed-off-by: Ran Benita <ran234@gmail.com>
clang complains with the xorg-macros warning flags:
src/context.c:58:36: error: extension used [-Werror,-pedantic,-Wlanguage-extension-token]
typeof(new_paths));
This was not entirely correct, too. So bring back the casts to the
results of the allocation macros; might as well make them a bit more
type safe.
Signed-off-by: Ran Benita <ran234@gmail.com>
The two files do exactly the same sort of things, without any discernible
reason for splitting them.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb_desc -> xkb_keymap changes.]
'Cause defining your own True and False is so 1990's.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Fixed for xkb_desc -> xkb_keymap changes.]
Since the most common failure mode here is a failure to properly set the
XKB data path, dump the include path so people at least have a clue
where to look.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
POSIX specifies that these functions require <strings.h>, but we were
only including <string.h>. It did work, but still.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
This is very useful because it avoids redundent pointers in structs
and/or parameter passing in the application.
Signed-off-by: Ran Benita <ran234@gmail.com>
The definitions in config.h should be available in all files an
implementation detail; it can be included through the build system
instead of having each file pull it every time.
This is especially helpful with AC_USE_SYSTEM_EXTENSIONS, as _GNU_SOURCE
and friends can have an effect by merely being defined, which can lead
to some confusion if its effective for only half the files.
And we don't really support a build _without_ config.h; so, one less
thing to worry about.
Signed-off-by: Ran Benita <ran234@gmail.com>
The kbproto header is already not needed here anymore.
Move the _X_EXPORT's to the corresponding function definitions, and use
straight extern "C" clauses instead of _XFUNCPROTOBEGIN/END.
It also makes more sense to have the EXPORT's in the source files, as it
provides some documentation to the reader, whereas in the header it's
obvious.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb_keymap changes.]
xkb_state_ref was missing.
Also modify the _ref functions to return the object instead of being
void. This is a useful idiom:
struct my_object my_object_new(struct xkb_state *state)
{
[...]
my_object->state = xkb_state_ref(state);
[...]
}
Essentially "taking" a reference, such that you don't forget to
increment it and it's one line less (see example in our own code).
A case could also be made for _unref to return the object or NULL, but
this is quite uncommon.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb_keymap changes.]
When merging group info from two KeyInfo's, the new size of the keysym
array was off. Fix it to match how it is used a few lines below.
There are also some peripheral fixes, and some comments (took me a
few minutes to get what's going on).
Signed-off-by: Ran Benita <ran234@gmail.com>
(They were not reported, see next commit).
The reset function declaration didn't match its name in the definition;
the _defaults variant matches better with the rest.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated to current master.]
Various one-liners (mostly removing unused variables) to make the code
safe for the full set of warnings used by the xorg macros.
On Debian-based systems, flex generates incorrect code resulting in two
warnings about yy_getcolumn and yy_setcolumn having no previous
declaration despite being non-static. Fedora carries a patch to fix
this, and a bug has been filed on Debian's flex to add the patch:
http://bugs.debian.org/667027
Aside from this, it's now safe for --enable-strict-compilation.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
If a keysym was specified as "U1039andsomeextrastuffontheend", return
NoSymbol rather than 0x10001039; similarly, return NoSymbol for
"0xdeadbeefhitherehowsyourdaybeen" rather than 0xdeadbeef.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This change makes sure that include does not overwrite previous
compatibility modifier settings when the included files does not
explicitly specify them.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
[Cross-picked from xkbcomp commit 14470719.]
When xkb_free_keymap is called the atoms are all free'd, but action.c
keeps a global copy of interned "true" and "false", which remains stale.
The correct fix is to remove the need for the ActionsInit function
entirely.
Signed-off-by: Ran Benita <ran234@gmail.com>
These were several initializations that were forgotten in the previous
memory leak fixes.
Now several xkb_desc's can coexist (relatively) peacefully.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Only the atom.c is relevant with the new context API.]
The "makeit" variable is always true. Remove it and de-indent.
(Also change the type of the "len" variable to size_t to avoid some
useless casting).
Signed-off-by: Ran Benita <ran234@gmail.com>
The NULL check is unneeded, and prevented the atoms from being free'd.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb_map_unref.]
Such as:
Compiling path: ./test/data/bad.xkb mapName:
==1300== Conditional jump or move depends on uninitialised value(s)
==1300== at 0x4E46166: HandleVModDef (vmod.c:90)
==1300== by 0x4E3FEC9: HandleKeyTypesFile (keytypes.c:1035)
==1300== by 0x4E3FBE1: HandleIncludeKeyTypes.constprop.11 (keytypes.c:387)
==1300== by 0x4E401DD: HandleKeyTypesFile (keytypes.c:1022)
==1300== by 0x4E3FBE1: HandleIncludeKeyTypes.constprop.11 (keytypes.c:387)
==1300== by 0x4E401DD: HandleKeyTypesFile (keytypes.c:1022)
==1300== by 0x4E4026F: CompileKeyTypes (keytypes.c:1150)
==1300== by 0x4E3DF9B: CompileKeymap (keymap.c:169)
==1300== by 0x4E465E9: compile_keymap (xkbcomp.c:205)
==1300== by 0x4E46BE4: xkb_compile_keymap_from_file (xkbcomp.c:290)
==1300== by 0x400B37: test_file (filecomp.c:47)
==1300== by 0x4008E3: main (filecomp.c:90)
==1300== Uninitialised value was created by a stack allocation
==1300== at 0x4E3FB3F: HandleIncludeKeyTypes.constprop.11 (keytypes.c:366)
Signed-off-by: Ran Benita <ran234@gmail.com>
If we can't find the component of the include file we're looking for,
make sure we don't return success when we meant failure, segfault, or
spectacularly leak everything.
Tested with incorrect component includes for keycodes, compat, symbols,
and types.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reported-by: David Herrmann <dh.herrmann@googlemail.com>
Which also involved moving the global symbol map to be per-key instead;
this should probably be split out into a separate commit.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Instead of allowing only one keysym per level per group, do as the
external API indicates and allow multiples. The existing syntax is:
key <AD01> { [ q, Q ] };
where the new syntax is:
key <AD01> { [ q, Q, { H, E, L, L, O },
{ Y, E, S, space, T, H, I, S, space, I, S, space, D, O, G } };
to make the key in the extreme top left of the keyboard do pretty
surprising things in levels 3 and 4.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
All global state is removed from the parser and scanner.
This makes use of the standard facilities in Bison and Flex for
reentrant/pure scanner/lexer and location tracking.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated to current sources.]
Unify all the different Makefile.am into a single short top level one
(the test/Makefile.am file is left intact though).
This makes the build system simpler to look and should encourage
unifying more currently-disparate code.
Some further motivation can be found in this page:
http://www.flameeyes.eu/autotools-mythbuster/automake/nonrecursive.html
Signed-off-by: Ran Benita <ran234@gmail.com>
Since we have our own xkb_keysym_t type, it makes sense to have our own
NoSymbol value instead of the one from X11/X.h.
Signed-off-by: Ran Benita <ran234@gmail.com>
Since we define our own xkb_atom_t type, it makes sense not to use the
X11/X.h None value. This way we can also remove a lot of X11 includes.
Signed-off-by: Ran Benita <ran234@gmail.com>
i.e comparison of signed and unsigned values. These are mostly
harmless but fixing them allows to compile cleanly with -Wextra.
Signed-off-by: Ran Benita <ran234@gmail.com>
There are some cases where we must free a string with a const qualifier.
Add a macro UNCONSTIFY to trick the compiler into silencing the warning
in the cases where we know what we're doing.
Signed-off-by: Ran Benita <ran234@gmail.com>
And merge all the similar ones into the same name.
The u* prefix is chosen over the _Xkb prefix because it has more uses
throughout the codebase. But It should now be simple to choose a nice
prefix and stay consistent.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: fixed for the case where we have strcasecmp]
Some unused defines and geometry-removal leftovers (specifically the
file geom.c and the struct for the keyboard coordinates).
Signed-off-by: Ran Benita <ran234@gmail.com>
The recalloc function should be expressed in terms of bytes to match its
name. However uTypedRecalloc retains its type so nothing is changed.
Signed-off-by: Ran Benita <ran234@gmail.com>
Sorry if your libc doesn't have this, but it's not my problem.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reported-by: Ran Benita <ran234@gmail.com>
GCC complained:
misc.c:235:13: warning: logical 'and' of mutually exclusive tests is always false [-Wlogical-op]
misc.c:248:13: warning: logical 'and' of mutually exclusive tests is always false [-Wlogical-op]
Looking at keysymdef.h shows that the check is indeed wrong. This commit
updates the check to match the latin8 section of keysymdef exactly.
Signed-off-by: Ran Benita <ran234@gmail.com>
Use XKB_KEY_UP instead of 0 and XKB_KEY_DOWN instead of 1.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reported-by: Ran Benita <ran234@gmail.com>
And also convert state.c to use the state API for mods and groups,
rather than testing the state members directly.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This resulted in duplicate sets of modifiers, since we were comparing
pointer equality of two strings, rather than string equality. Oops.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Add new API to deal with xkb_state objects, including
xkb_state_update_key, which runs the XKB action machinery internally to
calculate what exactly happens to the state when a given key is pressed
or released.
The canonical way to deal with keys is now:
struct xkb_state *state = xkb_state_new(xkb);
xkb_keysym_t *syms;
int num_syms;
xkb_state_update_key(state, key, is_down);
num_syms = xkb_key_get_syms(state, key, &syms);
More state handling API, including a way to get at or ignore preserved
modifiers, is on its way.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Previously, we would clear out the real modmask when updating the
modmask for action maps, if not using the key's modmask. The correct
behaviour here is instead to use the key's modmask if using the modmap,
else use the real mods provided with the action originally.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Unfortunately we can't get the actual file it was defined in this far
down, but at least give the human-readable name rather than just a group
index.
Also, groups are not zero-indexed, such that index 0 is group 1; fix
that too.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Instead of generating a fairly droll internal error, generate a warning
also telling us exactly where the bad definition was.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
By ensuring their mask is only the vmods, rather than also potentially
including the key's modmap. Also remove the unnecessary vmodmask
indirection.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The server used to have to go and do this on our own, but we can do
better than that: after we've compiled the keymap, go through and bind
virtual modifiers to everything that needs it.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Right now we just silently ignore overlay controls, which is probably
bad, but it's not the easiest to fix.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
It looks like this could never have worked anyway, what with num_rg
always being 0 everywhere. Remove it.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
They're no longer needed since we don't expose any atoms in the
published API anymore. As a result, we don't need to support external
atom implementations either. Result!
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
On many layouts, the following error appears:
Internal error: Could not resolve keysym 10005b0
(Which is like the trademark of libxkbcommon now, and makes
unicode-heavy symbol files pretty useless).
This occurs when a keysym string (in this case, 10005b0) is passed to
xkb_string_to_keysym, but cannot be resolved.
This in turn happens because the parser passes on hexadecimal keysym
strings without the leading "0x", thus leaving the resolving function
without a way to disambiguate it as a number.
Therefore, make sure to pass on the "0x". The file symbols.c in xkbcomp
project does the same; it probably got lost in translation.
Signed-off-by: Ran Benita <ran234@gmail.com>
This needlessly occupies memory for the lifetime of the library, and
does not make a noticeable difference otherwise.
This rules file won't be loaded more than once in most cases anyway, so
just load it again when it happens.
Signed-off-by: Ran Benita <ran234@gmail.com>
This needlessly occupies memory for the lifetime of the library, and
does not make a noticeable difference otherwise.
Instead, just parse the same file again when it happens.
Signed-off-by: Ran Benita <ran234@gmail.com>
The yacc implementation can generate all the necessary token
definitions itself; there is no need to maintain a hand written
file for that.
Signed-off-by: Ran Benita <ran234@gmail.com>
This integrates two commits from libX11:
ebd6ef0a4db0ddef0ae17ad14571518ccdeea5ba
XStringToKeysym: Special case for XF86 keysyms
Some XFree86 keysyms were in XKeysymDB as XF86_foo, despite really being
XF86foo. So, if we get to the bottom of XStringToKeysym and haven't
found our XF86_foo, try it again as XF86foo.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
00175397480b76d32bf82b0c7c94c91a2a95954e
makekeys: Scan vendor keysyms as well as core
Since we can't really live without vendor keysyms, scan them all in to
generate ks_tables.h, rather than only doing the core ones, and leaving
the vendor syms to be manually synchronised with XKeysymDB.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Notice that the xkey.sh test is changed to match libX11 behavior, i.e.
XKeysymToString(0x1008FE20) -> "XF86Ungrab" as opposed to "XF86_Ungrab".
Signed-off-by: Ran Benita <ran234@gmail.com>
This matches commit 24283d40b1e4314c6647dda49d2a159833341a8b from
libX11:
Since makekeys is built using build environment's compiler and
runs natively, we have to make sure that the size of the
Signature type is the same on both the native environment
and the target, otherwise we get mismatches upon running X,
and some LSB test failures (xts5).
Use an unsigned 32-bit integer on all platforms.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Ran Benita <ran234@gmail.com>
Fix all reported null dereferences from clang-analyzer.
There seems to be one false negative (in file indicators.c), but it is
fixed anyway.
Signed-off-by: Ran Benita <ran234@gmail.com>
Every caller did the exact same check on the group bounds after calling
ExprResolveGroup, so might as well do it inside.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
We never want to solely lookup a virtual modifier without also looking
up core modifiers. So, rather than chaining the vmod lookup inside the
core modifier lookup, invert the ordering.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
None of the lookup functions anyone ever used supported field
references, so don't pretend we do in the API.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
groupNames was declared in compat.c as a global to anything which
included compat.h (for which groupNames was its sole reason to exist),
but only ever used in indicators.c.
Which is kind of fortunate, given that e314931e removed identical
definitions of groupNames (as integers, not masks) from both action.c
and symbols.c.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Move the bulk of ExprResolveInteger into an internal function called
ExprResolveIntegerLookup, and introduce ExprResolveInteger as a simple
wrapper which doesn't take priv/lookup arguments.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Because, joke's on you, it wasn't actually looking up radio groups.
Just checking to see if it was a string that was "none", or an integer.
Lord give me strength.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Which is just a slightly more typesafe wrapper around the chained
ExprResolveModMask everyone was using earlier.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Make sure we carry over an explicit minimum/maximum keycode setting,
rather than just using the computed minimum/maximum; this got broken
while changing the keycode range to be unsigned.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reported-by: Pekka Paalanen <ppaalanen@gmail.com>
Thanks to autotools happily building stale generated sources, I hadn't
actually ever built my xkbparse.y changes. Fix that so it not only
compiles, but works. This seems to parse long keycodes correctly,
although I very much would not recommend testing this by declaring
0x1fffffff as your highest keycode.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Some error paths don't set info->xkb correctly, so just do like most
utility functions and pass the xkb_desc explicitly.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
And use it consistently everywhere, including with a special long-safe
internal keycode type, to ease the transition to large keycodes.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
For some reason, lex decided to reduce a strcpy into an assignment,
leading to entirely justified valgrind warnings about invalid reads,
when scanFile was set to a string which may have only ever lived on the
stack of a now-exited function.
Make it a strdup() instead.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Some routes through HandleGeometryVar do not set a return value. Set a default
value for the return variable to avoid returning an uninitialised value.
Which just calls XkbcFreeKeyboard with the only arguments you'd ever
pass it.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Avoids assigning the global pointer to a value that may only have a stack
lifetime:
Fixes valgrind warnings such as:
==24795== Invalid read of size 1
==24795== at 0x4A06E9A: strcpy (mc_replace_strmem.c:311)
==24795== by 0x4E54D68: ProcessIncludeFile (misc.c:73)
==24795== by 0x4E59726: HandleIncludeSymbols.constprop.3 (symbols.c:829)
==24795== by 0x4E59D8E: HandleSymbolsFile (symbols.c:1673)
==24795== by 0x4E5A068: CompileSymbols (symbols.c:2211)
==24795== by 0x4E51A61: CompileKeymap (keymap.c:155)
==24795== by 0x4E5B410: xkb_compile_keymap_from_components (xkbcomp.c:236)
==24795== by 0x4E5B587: xkb_compile_keymap_from_rules (xkbcomp.c:161)
==24795== by 0x405ED2: display_create (window.c:2007)
==24795== by 0x403732: main (desktop-shell.c:320)
==24795== Address 0x7fefff0a0 is just below the stack ptr. To suppress, use:
--workaround-gcc296-bugs=yes
==24795==
==24795== Source and destination overlap in strcpy(0x7fefff430, 0x7fefff430)
==24795== at 0x4A06F3D: strcpy (mc_replace_strmem.c:311)
==24795== by 0x4E54D68: ProcessIncludeFile (misc.c:73)
==24795== by 0x4E59726: HandleIncludeSymbols.constprop.3 (symbols.c:829)
==24795== by 0x4E59D8E: HandleSymbolsFile (symbols.c:1673)
==24795== by 0x4E5A068: CompileSymbols (symbols.c:2211)
==24795== by 0x4E51A61: CompileKeymap (keymap.c:155)
==24795== by 0x4E5B410: xkb_compile_keymap_from_components (xkbcomp.c:236)
==24795== by 0x4E5B587: xkb_compile_keymap_from_rules (xkbcomp.c:161)
==24795== by 0x405ED2: display_create (window.c:2007)
==24795== by 0x403732: main (desktop-shell.c:320)
Those warnings disappear accordingly:
| CC parseutils.lo
| parseutils.c:742: warning: no previous prototype for ‘CheckDefaultMap’
| CC xkbscan.lo
| xkbscan.l: In function ‘XKBParseString’:
| xkbscan.l:220: warning: implicit declaration of function ‘CheckDefaultMap’
| xkbscan.l:220: warning: nested extern declaration of ‘CheckDefaultMap’
Reviewed-by: Dirk Wallenstein <halsmit@t-online.de>
Signed-off-by: Cyril Brulebois <kibi@debian.org>
There's no need for this xlib include:
| YACC xkbparse.c
| CC xkbparse.lo
| xkbparse.y:98:22: error: X11/Xlib.h: No such file or directory
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
This would cover the scenario where these headers file are updated,
for example, a new version is installed. Running 'make' again
on libxkbcommon should rebuild ks_tables.h.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
This program is a utility to generated a header file.
The header file it generates should not be located in the
directory where this utility program is compiled.
Move the /makekeys dir as a sibling of /src.
This reduces the number of bi-directional relationships
between directories.
Make corresponding makefiles simplifications.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
These automake variables are not currently used.
The variable KS_HEADERS is not required anymore.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
BUILT_SOURCES and MAINTAINERCLEAN are not needed for lex and yacc
Note that xkbscan was missing on those lines.
Automake generates all the rules to handle building, distribution
and cleaning.
Acked-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Fixes automake warning.
Acked-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
xkbscan.l: In function 'setScanState':
xkbscan.l:201:1: warning: control reaches end of non-void function
I: Program returns random data in a function
E: libxkbcommon no-return-in-nonvoid-function xkbscan.l:201
Change return type of setScanState to void, since a return value is
never used by its callers.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Use -no-undefined to assure libtool that the libxkbcommon library has
no unresolved symbols at link time, so that libtool will build a shared
library on platforms require that all symbols are resolved when the
library is linked.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Keep the parsed form of the last-used rules file around, and reuse that
if we get asked for the same ruleset. If not, bin it and cache the
other one.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Use CARD32 instead of Atom/KeySym/et al to avoid type size confusion
between server and non-server code; relatedly, move the geometry headers
in from kbproto, so every non-simple type (i.e. structs containing
nothing more than basic types) is now copied into xkbcommon.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Allow people to plug in an external atom database (e.g. the X server's),
so we don't have to migrate our own atoms over later. We are a bit
over-keen on atoms at the moment, so it does pollute the atom database a
bit though.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
On 64-bit architectures, XID varies in size between the server (always
32 bits), and non-server (always unsigned long) for some inexplicable
reason. Use CARD32 instead to avoid this horrible trap.
This involves dragging in XkbClientMapRec so we don't get stuck in the
KeySym trap.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Use Xkbc* for all our actions that we intend to keep around, and Xkb*
for deprecated ones we can hopefully get rid of, at least internally.
While we're at it, make vmods be a uint32_t.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
So, it turns out that if you're parsing a fairly large amount of data,
using getc() to get all the input rather than, say, read(), is some kind
of remarkably daft and unperformant idea.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Instead of calling XStringToKeysym on every keysym we parse, store it as
a string until we need to store it in an actual keymap.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
XkbAtomGetString() returns a freshly-allocated string, whereas
XkbAtomText() returns the same in a temporary buffer. XkbAtomText used
to call XkbAtomGetString() and then free the result, which seems quite
spectacularly pointless when you think about it. Shuffle the atom code
around so we don't have to allocate for XkbAtomText().
This changes semantics slightly wrt non-printable characters, but I
haven't been able to see any effect so far. And it may well be ever so
slightly quicker.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This will let us implement XkbAtomGetString on top of XkbAtomText,
instead of having the latter get a duplicated string, dump it into a
temporary buffer, and subsequently free it (sigh).
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
XkbcInternAtom(XkbcAtomGetString(atom)) has to be the most spectacularly
broken antipattern I've yet seen. Just compare the atoms directly.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Canonicalises two sets of components (new and old), e.g.:
new: +bar
old: foo
result: foo+bar
This is required as part of the spec, so clients can reuse part of the
device's old keymap.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ensure that Unicode string representations are accepted and turned into
numbers, as well as hexadecimal numbers in 0xabcd1234 form; unknown
keysyms are output as 0xabcd1234 in string form.
This also ensures that strings are never returned malloc()ed.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Add NoSymbol into the keysym table, so keysym <-> string conversion works for
that, too; also eliminate special-casing of VoidSymbol.
This will require special-casing in libX11 to preserve its API.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The listing code in xkbcomp had been setup to allocate a set of buffers
with file paths and then later parse through them to find which maps were
needed.
All the allocation (with the additional allocation for the components
list) was making it really slow, so this patch makes everything simpler
by just generating the components list as we walk the directory tree.
In xkbcomp, the listing code printed out the xkb files to stdout and the
caller would parse the output. Here, we can just generate a
XkbComponentListPtr and pass it back.
This should be a series of smaller commits, but there was no clean way to
do it since it's basically a complete rewrite except for the core map
matching logic.
A lot of code used for special printing modes in xkbcomp has been
shedded. Callers can massage the output as they please.
This reverts commit c4c9e36fbf. It turns
out that the listing code is used to support the X_kbListComponents
request (via XkbListComponents).
This will have to be refactored into some reasonable interface instead
of the current usage where the server reads xkbcomp stdout. Gross.
Instead of hardcoding the XKB base directory when searching for rules in
the xkbcomp code, we can extend the xkbpath API to cover rules and reuse
it. That will make it more convenient if it's ever exposed so people can
set their XKB search paths in a reasonable way.
We need to support generating a keyboard description from a keymap file
because there are just some cases where RMLVO or ktcsg is not enough.
The map choosing logic has been refactored into its own function and now
supports choosing a named or default keymap.
The noble intention was to expose all the new API and new generic types
in the split out kbproto headers through XKBcommon.h. It turns out that
would be a massive amount of work in the server. Someday, but first just
wedging in XkbCompileKeymap* would be good.
Most of the API is in new internal xkb*.h headers. In order to allow the
XKBcommon.h header to be used from the server, we can't pull in other
headers from kbproto since the server has its own copies. However, types
that are different (XkbDescRec, XkbAction) still have Xkbc equivalents
here, and I think they should be used in the server.
Some of the XkbAction types are defined differently in the server, so we
add those to XKBcommon.h and use them here like XkbcDescPtr. We'll have
to deal with the impedance mismatch on the client side later.
XkbcRF_GetComponents was returning an error but leaving the generated
components alone. This ensures that the broken XkbComponentNamesPtr is
freed and the error is passed up to the caller.
Instead of requiring the user to call XkbInitIncludePath() and
XkbAddDefaultDirectoriesToPath(), all the path entry points now implicitly
initialize the path. When initializing, the default directories are added
so it's useful.
This provides normal operation without exposing the xkbpath API. That
might happen later to allow apps to edit the XKB search path.
XkbcCompileKeymapFromRules can be used to generate a XkbDescPtr from XKB
rules instead of using components. The previous XkbcCompileKeymap has
been renamed to XkbcCompileKeymapFromComponents.
Copy over the Xkb_RF* rules parsing functions from xkbfile's maprules.c.
Eventually, this will be tied into xkbcomp's path searching utilities so
you don't need to supply a full path to the rules file. Also, it this
should eventually incorporate the server's RMLVOSet.
Finally, we can generate a XkbcDescPtr from a XkbComponentNamesPtr. This
involves turning the components into a parsed XKB file and then passing
it into the compiler. This first conversion needs more error handling.
xkbcomp was using Xlib's XConvertCase to check upper/lowercase. That's a
lot of code, so hopefully the xkbfile macros using _XkbKSCheckCase are
good enough. This also required that <X11/keysym.h> is included to get
all the XK_* definitions.
Added common variants of XkbComputeEffectiveMap, XkbInitCanonicalKeyTypes
and all their needed functions. A couple functions that were in alloc.c
moved to malloc.c to mirror the libX11 sources better.
Original code in
libX11/src/xkb/XKBMalloc.c
libX11/src/xkb/XKBMisc.c
libX11/src/xkb/XKB.c
This should cover all the usage in xkbcomp. The format arguments were
dropped except for the special case of XkbModMaskText, which needs to
write in XkbCFile format in HandleVModDef. This was just changed to a
Bool to avoid the need for the macros in XKBfile.h.
The function prefixes have been renamed to be unique from xkbfile.
The only real usage was in the frontend to generate a .xkm file. The
rest of the code just operated on the attached XkbDescPtr. Note that
here we've replaced the usage of the defined field in CompileKeymap with
the equivalent field in a XkbcDescPtr.
A copy of the xkbcomp sources (except the frontend) have been copied in
to provide a means to compile a XkbDescPtr. This definitely doesn't
build or do the right thing yet.
This avoids the BUILT_SOURCES weirdness and forcing the build into the
makekeys subdirectory. Added a new make variable KS_HEADERS that lists
all the keysym headers we're going to parse.
Some coding style nits were cleaned up. Additionally, most of the
functions have been collapsed from the libxkbfile version where there's
distinction with the Xlib atom functions when Display was set. Finally,
the InitAtoms function tests whether the table has already been created
by testing the pointer rather than using a static int.
Mostly tab-to-space conversion plus a few style nits. Dropped the
register keywords as I'm pretty sure modern compilers can be trusted to
do the right thing.
Following the kbproto convention, the headers will be named XKBcommon.h
and XKBcommonint.h. Furthermore, they'll be installed in X11/extensions
directory with the rest of the XKB headers.
Copies the code to initialize and destroy an XkbDescRec from libX11. The
original code is in
libX11/src/xkb/XKBAlloc.c
libX11/src/xkb/XKBGAlloc.c
libX11/src/xkb/XKBMAlloc.c
These are used throughout the XKB code, but are defined in XKBsrv.h,
which we'd like to avoid. Internal definitions for True/False have also
been added since they're in Xlib.h
Mostly tab-to-space conversion plus a few style nits. Dropped the
register keywords as I'm pretty sure modern compilers can be trusted to
do the right thing.
Add the xkbcommon implementations of XKeysymToString and XStringToKeysym.
These symbols have the namespace prefix of Xkbc and are declared in
X11/XkbCommon.h.
The implementation is taken directly from Xlib, but does not include the
XKeysymDB parsing and hashing yet (if it ever will). A couple type
conversions were needed to keep from using Xlib.h. See original files:
libX11/src/KeysymStr.c
libX11/src/StrKeysym.c
The makekeys utility is used to generate the keysym hash tables during
the build. We try to detect a build machine native compiler so the
tables can be generated when cross compiling.
Ran Benita
Daniel Stone
Rob Bradford
Pekka Paalanen
Kristian Høgsberg
Alan Coopersmith
Cyril Brulebois
Gaetan Nadon
Jan Engelhardt
Jon TURNEY
Adam Jackson
Dan Nicholson