|
c0065c95
|
2023-09-21T20:06:27
|
|
Messages: merge macros with and without message code
Previously we had two types of macros for logging: with and without
message code. They were intended to be merged afterwards.
The idea is to use a special code – `XKB_LOG_MESSAGE_NO_ID = 0` – that
should *not* be displayed. But we would like to avoid checking this
special code at run time. This is achieved using macro tricks; they
are detailed in the code (see: `PREPEND_MESSAGE_ID`).
Now it is also easier to spot the remaining undocumented log entries:
just search `XKB_LOG_MESSAGE_NO_ID`.
|
|
|
a83d745b
|
2023-09-21T20:06:27
|
|
Messages: add new messages to registry
This commit is another step to identify and document the maximum number
of logging messages. Bulk changes:
- Rename `conflicting-key-type` to `conflicting-key-type-merging-groups`.
Giving more context in the name allow us to introduce
`conflicting-key-type-definitions` later.
- Add conflicting-key-type-definitions
- Add conflicting-key-type-map-entry
- Add undeclared-modifiers-in-key-type
Also improve the log messages.
- Add conflicting-key-type-preserve-entries
- Use XKB_ERROR_UNSUPPORTED_MODIFIER_MASK
- Add illegal-key-type-preserve-result
- Add conflicting-key-type-level-names
- Add duplicate-entry
- Add unsupported-symbols-field
- Add missing-symbols-group-name-index
- Use XKB_ERROR_WRONG_FIELD_TYPE
- Add conflicting-key-name
- Use XKB_WARNING_UNDEFINED_KEYCODE
- Add illegal-keycode-alias
- Add unsupported-geometry-section
- Add missing-default-section
- Add XKB_LOG_MESSAGE_NO_ID
- Rename log_vrb_with_code to log_vrb
- Use ERROR_WRONG_FIELD_TYPE & ERROR_INVALID_SYNTAX
- Add unknown-identifier
- Add invalid-expression-type
- Add invalid-operation + fixes
- Add unknown-operator
- Rename ERROR_UNKNOWN_IDENTIFIER to ERROR_INVALID_IDENTIFIER
- Add undeclared-virtual-modifier
- Add expected-array-entry
- Add invalid-include-statement
- Add included-file-not-found
- Add allocation-error
- Add invalid-included-file
- Process symbols.c
- Add invalid-value
- Add invalid-real-modifier
- Add unknown-field
- Add wrong-scope
- Add invalid-modmap-entry
- Add wrong-statement-type
- Add conflicting-key-symbols-entry
- Add invalid-set-default-statement
|
|
|
ef81d04e
|
2023-09-18T18:17:34
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
|
|
4884a8e6
|
2013-08-02T10:19:01
|
|
keymap: move XkbEscapeMapName() to keymap.c.
So we can use it outside src/xkbcomp; it is not really specific to it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
9dc5b8cb
|
2013-11-27T13:49:13
|
|
Resolve keysyms early in parser
Instead of having the parser passing strings to the AST, and
symbols/compat etc. resolving them themselves. This simplifies the code
a bit, and makes it possible to print where exactly in the file the bad
keysym originates from.
The previous lazy approach had an advantage of not needlessly resolving
keysyms from unrelated maps. However, I think reporting these errors in
*any* map is better, and the parser is also a bit smarter then old
xkbcomp and doesn't parse many useless maps. So there's no discernible
speed/memory difference with this change.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
4b560287
|
2013-07-18T14:50:21
|
|
xkbcomp: escape the section names before storing them in the keymap
This ensures the names are escaped before having any interaction with
the user.
This was caught by noticing dump(compile(dump())) != dump. Since that's
a nice test we add it to stringcomp.
https://bugs.freedesktop.org/show_bug.cgi?id=67032
Reported-By: Auke Booij
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
a392d268
|
2012-08-12T11:40:02
|
|
Replace flex scanner with a hand-written one
The scanner is very similar in structure to the one in xkbcomp/rules.c.
It avoids copying and has nicer error reporting.
It uses gperf to generate a hashtable for the keywords, which gives a
nice speed boost (compared to the naive strcasecmp method at least). But
since there's hardly a reason to regenerate it every time and require
people to install gperf, the output (keywords.c) is added here as well.
Here are some stats from test/rulescomp:
Before:
compiled 1000 keymaps in 4.052939625s
==22063== total heap usage: 101,101 allocs, 101,101 frees, 11,840,834 bytes allocated
After:
compiled 1000 keymaps in 3.519665434s
==26505== total heap usage: 99,945 allocs, 99,945 frees, 7,033,608 bytes allocated
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
36f55c49
|
2013-03-11T12:53:39
|
|
keymap: add xkb_keymap_new_from_buffer()
The current API doesn't allow the caller to create keymaps from mmap()'ed
files. The problem is, xkb_keymap_new_from_string() requires a terminating
0 byte. However, there is no way to guarantee that when using mmap() so a
user currently has to copy the whole file just to get the terminating zero
byte (assuming they cannot use xkb_keymap_new_from_file()).
This adds a new entry xkb_keymap_new_from_buffer() which takes a memory
location and the buffer size in bytes.
Internally, we depend on yy_scan_{string,byte}() helpers. According to
flex documentation these already copy the input string because they are
wrappers around yy_scan_buffer().
yy_scan_buffer() on the other hand has some insane requirements. The
buffer must be writeable and the last two bytes must be ASCII-NUL. But the
buffer may contain other 0 bytes just fine.
Because we don't want these constraints in our public API,
xkb_keymap_new_from_buffer() needs to create a copy of the input memory.
But it then calls yy_scan_buffer() directly. Hence, we have the same
number of buffer-copies as with *_from_string() but without the
terminating 0 requirement.
The explicit yy_scan_buffer() call is preferred over yy_scan_byte() so the
buffer-copy operation is not hidden somewhere in flex.
Maybe some day we no longer depend on flex and can have a zero-copy API. A
user could mmap() a file and it would get parsed right from this buffer.
But until then, we shouldn't expose this limitation in the API but instead
provide an API that some day can work with zero-copy.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
[ran: rebased on top of my branch]
Conflicts:
Makefile.am
src/xkbcomp/xkbcomp.c
|
|
|
14842d6d
|
2013-03-01T21:48:02
|
|
keymap: abstract a bit over the keymap format
Make it a bit easier to experiment with other formats.
Add a struct xkb_keymap_format_operations, which currently contains the
keymap compilation and _get_as_string functions. Each format can
implement whatever it wants from these.
The current public entry points become wrappers which do some error
reporting, allocation etc., and calling to the specific format. The
wrappers are all moved to src/keymap.c, so there are no XKB_EXPORT's
under src/xkbcomp/ anymore.
The only format available now is normal text_v1.
This is all not very KISS, and adds some indirection, but it is helpful
and somewhat cleaner.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
dd81d5e0
|
2013-02-08T00:07:28
|
|
Change some log functions to take ctx instead of keymap
They don't need the keymap, only the context.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
fc56b513
|
2013-02-08T00:02:49
|
|
ast: constify argument
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
1c880887
|
2012-09-30T11:55:11
|
|
Don't scan and parse useless maps
One physical xkb file may (and usually does) contain multiple maps. For
example, the us symbols file contains a map for every variant.
Currently, when we need a map from a file (specific or default), we
parse the entire file into a list of XkbFile's, find the map we want and
discard the others. This happens for every include statement. This is a lot
of unnecessary work; this commit is a first step at making it better.
What we do now is make yyparse return one map at a time; if we find what
we want, we can stop looking and avoid processing the rest of the file.
This moves some logic from include.c to parser.y (i.e. finding the
correct map, named or default). It also necessarily removes the
CheckDefaultMap check, which warned about a file which contains multiple
default maps. We can live without it.
Some stats with test/rulecomp (under valgrind and the benchmark):
Before:
==2280== total heap usage: 288,665 allocs, 288,665 frees, 13,121,349 bytes allocated
compiled 1000 keymaps in 10.849487353s
After:
==1070== total heap usage: 100,197 allocs, 100,197 frees, 9,329,900 bytes allocated
compiled 1000 keymaps in 5.258960549s
Pretty good.
Note: we still do some unnecessary work, by parsing and discarding the
maps before the one we want. However dealing with this is more
complicated (maybe using bison's push-parser and sniffing the token
stream). Probably not worth it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
ee4ab30e
|
2012-09-28T10:15:27
|
|
scanner: share code in XkbParse{File,String}
Some refactoring to prepare for changes in the parse() function.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
bbaa11c6
|
2012-09-21T14:58:31
|
|
Rename map.{c,h} to keymap.{c,h}
Seeing as we don't like "map" anymore.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
b2110705
|
2012-09-16T14:45:32
|
|
Organize src/ and test/ headers
- Add context.h and move context-related functions from xkb-priv.h to
it.
- Move xkb_context definition back to context.c.
- Add keysym.h and move keysym upper/lower/keypad from xkb-priv.h to it.
- Rename xkb-priv.h to map.h since it only contains keymap-related
definitions and declarations now.
- Remove unnecessary includes and some and some other small cleanups.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
8c1b1b0e
|
2012-08-29T15:02:40
|
|
Add xkbcomp/keymap.c and move some code there
Add CompileKeymap to do most of what compile_keymap_file does now, and
move UpdateKeymapFromModifiers along with it from (mostly unrelated)
compat.c.
Also rename UpdateKeymapFromModifiers to UpdateDerivedKeymapFields,
because it does more than update the modifiers.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
d3ddcf70
|
2012-08-15T21:45:02
|
|
expr: move op_type/value_type_to_string functions to ast
Generally the enum-to-string function should appear where the enum is
defined.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
cdc228ea
|
2012-08-13T11:00:43
|
|
Organize xkbcomp/ header files
Various non-functional changes:
- Re-add keycodes.h and move some stuff there.
- Add parser-priv.h for internal bison/flex stuff.
- Don't include headers from other headers, such that file dependencies
are immediate in each file.
- Rename xkbcomp.h -> ast.h, parseutils.{c,h} -> ast-build.{c,h}
- Rename path.{c,h} -> include.{c,h}
- Rename keytypes.c -> types.c
- Make the naming of XkbFile-related functions more consistent.
- Move xkb_map_{new,ref,unref} to map.c.
- Remove most extern keyword from function declarations, it's just
noise (XKB_EXPORT is what's important here).
- Append XKBCOMP_ to include guards.
- Shuffle some code around to make all of this work.
Splitting this would be a headache..
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
7bcc5fab
|
2012-08-10T13:32:58
|
|
keycodes: save context in Info, not keymap
We don't need the keymap in this case, just makes things more verbose.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
34e690ce
|
2012-08-10T13:08:03
|
|
Remove AutoKeyNames feature
If this keymap flag is set, whenever a key name appears in one of the
sections which does not exist (i.e. has not been declared in keycodes),
it finds the first unused keycode and attaches it that name.
This might have been useful when you could compile the symbols section
or geometry section without a keycodes section, but we don't support
this anymore. It's also pretty useless for any real work, because the
user has no way of knowing the keycode and so it will never be used.
Finally the only obscure way left to set this flag is by including a
keycodes file called "computed".
Just remove it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
07b18bde
|
2012-08-09T02:33:51
|
|
Modernize struct xkb_mods
Currently xkb_mods has the following members:
- uint8_t real_mods - 8 X11 core mods
- xkb_mod_mask_t vmods - 16 virtual mods, zero-based index
- xkb_mod_mask_t mask - the computed effective *real* modifier mask,
basically a cache for the first two which is:
real_mods | real mods computed from vmods
Our API acts on masks which combine the real_mods and vmods into a
single value, which is:
8 first bits real mods | 16 next bits virtual mods
(XkbNumModifiers = 8, XkbNumVirtualMods = 16). This is also the format
which ResolveVModMask uses (which is where all the modifier masks really
"come from", e.g. "Shift+Lock+Level5" -> xkb_mod_mask_t).
What the code does now after getting the mask from ResolveVModMask, is
to break it into real part and virtual part and store them seperately,
and then join them back together when the effective mask is calculated.
This is all pretty useless work. We change xkb_mods to the following:
- xkb_mod_mask_t mods - usually what ResolveVModMask returns
- xkb_mod_mask_t mask - the computed mask cache
And try to consistently use the word "mods" for the original,
non-effective mods and mask for the effective mods (which can only
contain real mods for now, because things break otherwise).
The separation is also made clearer. The effective masks are computed by
UpdateModifiersFromCompat after all the sections have been compiled;
before this the mask field is never touched; after this (i.e. map.c and
state.c) the original mods field is never touched. This single execption
to this rule is keymap-dump.c: it needs to print out only the original
modifiers, not computed ones. This is also the reason why we actually
keep two fields instead keeping one and modifying it in place.
The next logical step is probably to turn the real mods into vmods
themselves, and get rid of the distinction entirely (in a compatible
way).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
b2c4331a
|
2012-07-28T22:15:59
|
|
Handle key names consistently
We treat the key names as fixed length, non NUL terminated strings of
length XkbKeyNameLength, and use the appropriate *Text functions to
print them. We also use strncpy everywhere instead of memcpy to copy
the names, because it does some NUL padding and we might as well.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
3bea189b
|
2012-08-01T18:46:01
|
|
Make top level Handle*File functions nicer
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
6cb98200
|
2012-07-24T13:15:40
|
|
Use xkb_mod_mask_t and xkb_mask_index_t throughout
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
74be1762
|
2012-07-23T21:30:28
|
|
Remove alloc.{c,h}
These functions are more appropriate elsewhere now.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
70e3e7e5
|
2012-07-21T15:39:18
|
|
xkbcomp: use new log functions
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
8e62b368
|
2012-07-21T01:35:46
|
|
compat: use new log functions
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
db98696d
|
2012-07-17T17:08:14
|
|
Remove CommonInfo
Not used by anything anymore.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
dfa0929c
|
2012-07-16T22:15:43
|
|
Convert macros to inline functions
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
e21fc886
|
2012-07-17T00:43:59
|
|
compat: use list instead of CommonInfo in SymInterpInfo
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
d0097f4e
|
2012-07-15T15:55:34
|
|
Pass around xkb_key's instead of keycodes
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>
|
|
9308a460
|
2012-07-17T10:20:15
|
|
Run source tree through uncrustify
.uncrustify.cfg committed for future reference also, but had to manually
fix up a few things: it really likes justifying struct initialisers.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
6c3e0811
|
2012-07-14T15:14:44
|
|
Convert missed enum merge_mode variables
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
43bf4136
|
2012-07-14T15:19:12
|
|
Fix fileID mess
A few problems here:
* In e.g. keycodes.c the fileID field of the Info struct was never
initialized to the id of the appropriate file, so it was always 0.
There's some code which uses it, mostly for warnings.
* Some of the fileID fields were unsigned char, which overflows several
times, seeing as the ID in some of our tests can get > 1000 (because
we reuse the context).
* Some sign mismatches.
* fileID vs file_id.
Hopefully this fixes everything. I doubt this stuff had ever worked as
intended, in xkbcomp or otherwise.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
3e65531f
|
2012-07-13T17:31:30
|
|
Move ComputeEffectiveMap code and avoid some duplication
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>
|
|
|
48b4d30a
|
2012-06-29T17:05:33
|
|
Use enum for file types
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>
|
|
|
f637d35a
|
2012-06-27T00:22:31
|
|
Use void* instead of old style char* in CommonInfo functions
Removes some annoying casts.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
db3e8f2c
|
2012-05-13T10:14:10
|
|
Create path.h for the path.c functions
No need to stash them in xkbcomp-priv.h; files which need the functions
should explicitly include them.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
7b00485a
|
2012-05-11T15:03:43
|
|
Rename 'ctx' back to 'context' in external API
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>
|
|
|
e7bb1e5f
|
2012-05-09T15:03:11
|
|
Shorten context to ctx
(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.]
|
|
|
38cb6390
|
2012-05-09T15:15:30
|
|
Change all 'xkb' xkb_keymap names to 'keymap'
To make it a bit more clear what it actually is.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
b610b2b9
|
2012-05-08T14:52:23
|
|
Rename XKBcommonint.h to xkb-priv.h and use it
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>
|
|
|
33273304
|
2012-05-08T13:57:07
|
|
Rename xkbcomp/misc.h to xkbcomp-priv.h and use it
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>
|