and let the info always be the first argument to the various functions,
just for consistency (and it acting as the contex for this file).
Signed-off-by: Ran Benita <ran234@gmail.com>
Add new public API to provide the library users with some options to
control and customize the logging output from the library. It is based
upon the skeleton from the libabc demo libray:
https://git.kernel.org/?p=linux/kernel/git/kay/libabc.git
which is public domain and works pretty well.
This requires passing in the context object in every logging call, and
thus the conversion is done file by file. We also remove the global
warningLevel variable in favor of a verbosity level in the context,
which can be set by the user and is silent by default.
One issue is the ACTION calls, which, while nice, do not play very well
with line- and priority-based logging, and would require some
line continuation handling or keeping state or some other compromise. So
instead remove these and just inline them with their respective
warning/error. So instead of:
ERROR("Memory allocation failed\n")
ACTION("Removing all files on hardisk\n")
its something like that:
log_err("Memory allocation failed; Removing all files on harddisk\n")
Signed-off-by: Ran Benita <ran234@gmail.com>
The include/ dir is somewhat redundant and makes it just a bit harder to
handle the -I directives from out side of automake; without it the
default $(top_buildir) just works.
Here's also some further justifications I found:
http://smcv.pseudorandom.co.uk/2008/09/pc-uninstalled/
Signed-off-by: Ran Benita <ran234@gmail.com>
When including a file from another file, its possible to do something
like this:
include "+some(other)+files"
with the "+" or "|" in the beginning. What will happen then is that
instead of processing the include files separately and then merging into
the existing info, we instead start with the existing info and merge
into it as we go, as if it was written explicitly before the first "+".
It's not particulary clear what this may be useful for. Since it's not
used by xkeyboard-config, not documented anywhere (and google doesn't
bring up anything), completely untested and kind of ugly, remove this
"feature". It most likely never been used.
Signed-off-by: Ran Benita <ran234@gmail.com>
Taken from xserver/include/list.h. The changes made are:
* Drop the xorg_ prefix and some typedef from the end.
* Rename _for_each_entry macros to just _foreach (like darray).
* Rename list_is_empty to list_empty (like darray).
* Add a list_replace function which we use later.
Signed-off-by: Ran Benita <ran234@gmail.com>
This way we don't need to look up the key every time. We now only deal
with keycodes in the public API and in keycodes.c.
Also adds an xkb_foreach_key macro, which is used a lot.
Signed-off-by: Ran Benita <ran234@gmail.com>
This is 8 bits which hold how many groups the key has, what to do the
key group is out of bound and the group to redirect to if want to. This
may save a few bytes, but is really annoying. So instead, just lay out
the fields separately. We can optimize later in a sane way, with pahole,
bitfields, etc. if we want.
Signed-off-by: Ran Benita <ran234@gmail.com>
Instead of having a million arrays from the keycode to various
key-specific info in the keymap, add a single struct xkb_key to hold all
of the data for the key in one object. This way we can pass it around,
do some refactoring and make the code simpler. It's also nice to see
everything in one place.
The keys array is still indexed by keycode, which is suboptimal because
there may be a lot of holes (i.e. unused keycodes between min_key_code
and max_key_code). By the end of this series it would be abstracted
enough to replace it by a hash table or similar if there's ever a need.
Signed-off-by: Ran Benita <ran234@gmail.com>
We don't make this distinction anymore, and the separate allocations
just make it harder to reason about. Since we require that all of
symbols, types, compat etc. be present, we should just put stuff
directly in the keymap struct.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita