|
20329baf
|
2023-11-23T09:30:57
|
|
xkbcomp: Use `steal` for better memory handling
|
|
00e3058e
|
2023-11-06T21:53:51
|
|
Prevent recursive includes of keymap components
- Add check for recursive includes of keymap components. It relies on
limiting the include depth. The threshold is currently to 15, which
seems reasonable with plenty of margin for keymaps in the wild.
- Add corresponding new log message `recursive-include`.
- Add tests for recursive includes.
|
|
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.
|
|
5b5b67f2
|
2023-05-01T22:30:41
|
|
Add support for modmap None (#291)
Unlike current xkbcommon, X11’s xkbcomp allows to remove entries in
the modifiers’ map using “modifier_map None { … }”.
“None” is translated to the special value “XkbNoModifier” defined in
“X11/extensions/XKB.h”. Then it relies on the fact that in "CopyModMapDef",
the following code:
1U << entry->modifier
ends up being zero when “entry->modifier” is “XkbNoModifier” (i.e. 0xFF).
Indeed, it relies on the overflow behaviour of the left shift, which in
practice resolves to use only the 5 low bits of the shift amount, i.e.
0x1F here. Then the result of “1U << 0xFF” is cast to “char”, i.e. 0.
This is a good trick but too magical, so in libxkbcommon we will use
an explicit test against our new constant XKB_MOD_NONE.
|
|
40aab05e
|
2019-12-27T13:03:20
|
|
build: include config.h manually
Previously we included it with an `-include` compiler directive. But
that's not portable. And it's better to be explicit anyway.
Every .c file should have `include "config.h"` first thing.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
ade13130
|
2019-12-27T12:22:37
|
|
xkbcomp: downgrade "Symbol added to modifier map for multiple modifiers" log to a warning
This condition happens in xkeyboard-config keymaps and seems hard to
fix. Currently it incessantly spams people's logs who have no idea what
to do about it. So downgrade to "warning" level, so it doesn't show up
by default.
When working on keymaps, set `XKB_LOG_LEVEL=debug XKB_LOG_VERBOSITY=10`
to see all possible messages.
Refs https://github.com/xkbcommon/libxkbcommon/issues/111
Fixes https://github.com/xkbcommon/libxkbcommon/issues/128
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
400cc849
|
2019-11-12T20:04:13
|
|
ast: use a separate expr struct for action list
Currently it's under UnaryExpr, which just doesn't make sense.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
75d1110c
|
2019-03-23T23:29:29
|
|
symbols: add a comment to suppress warning from code analyzers
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
|
|
39082082
|
2016-02-28T00:33:19
|
|
keymap: share LevelsSameSyms()
The function is generic enough.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
c03834a1
|
2014-10-23T21:00:20
|
|
Reduce variable scopes
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
4a660d7f
|
2014-10-18T19:47:19
|
|
xkbcomp: remove file->topName
It is useless.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
a4c667ad
|
2014-10-17T00:13:48
|
|
symbols: don't warn about conflicting syms if they are the same
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
725ae134
|
2014-09-25T22:01:17
|
|
keymap: rename XkbKeyGroupWidth to XkbKeyNumLevels
The "width" terminology comes from the group*width+level layout of the
keysyms in a key, as used in the old implementations. We don't keep all
the keysyms of a key in one array so change it to a more accurate name.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
2c259f17
|
2014-09-25T21:55:52
|
|
symbols: improve FindKeyForSymbol()
A bit more involved, but can short circuit.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
485b736f
|
2014-09-25T21:25:39
|
|
symbols: use correct max value
xkb_level_index_t was initially uint16_t, now it's 32.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
1054962d
|
2014-09-11T02:55:51
|
|
symbols: use darray_foreach_from for nicer loop
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
61fed8da
|
2014-07-26T00:19:34
|
|
Replace darray_mem with a new darray_steal
That's a more declarative interface.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
07fb6a6c
|
2014-04-22T18:18:13
|
|
xkbcomp: don't align enum values
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
28a22ba2
|
2014-04-22T18:05:24
|
|
xkbcomp: use straight assignment instead of CopyModSet
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
787faf36
|
2014-04-22T12:23:36
|
|
keymap: don't use darray in xkb_mod_set
Instead just statically allocate the mods array (of size MAX_MOD_SIZE =
32). The limit is not going anywhere, and static allocations are nicer
(nicer code, no OOM, etc.). It's also small and dense enough.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
0f6bca2b
|
2014-04-22T11:33:47
|
|
keymap: rename xkb_foreach_key to xkb_keys_foreach
We'll use the format xkb_foos_foreach and xkb_foos_enumerate for the
various iterators.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
95aabeec
|
2013-02-09T19:10:56
|
|
symbols: use xkb_mod_set instead of entire keymap
The keymap is not removed entirely from the Info (just constified),
since it is still needed in AddKeySymbols() for looking up aliases. This
dependency will be removed in the future.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
b5655b3d
|
2013-02-08T14:39:38
|
|
vmod: take xkb_mod_set instead of the entire keymap
This is the only place where the modifier information is modified. We
will make it local to a given XKB file (after which it will be merged
into the keymap). Currently it changes the keymap directly, which
sidesteps the abstraction and leaves side-effects even if the XkbFile's
compilation fails.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
0b7c8d61
|
2013-02-08T14:32:47
|
|
action: take xkb_mod_set instead of the entire keymap
A couple of modiifer actions need this information, but not the entire
keymap.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
9fbcf6bb
|
2013-02-08T13:56:41
|
|
expr: take xkb_mod_set instead of the entire keymap
The modifier-resolving functions only need the modifier information.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
edc0aef5
|
2013-02-08T13:21:27
|
|
text: take xkb_mod_set instead of the entire keymap
The modifier printing functions only need the modifier information, they
don't care about keys or leds, etc.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
51a1df2f
|
2014-04-19T15:56:27
|
|
keymap: move ModNameToIndex from text.c and use it in keymap.c
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
120c5c31
|
2013-02-08T00:28:49
|
|
symbols: separate ctx
Same as was done for compat and types.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
caf8f3be
|
2014-02-22T23:43:19
|
|
symbols, keycodes: fix int return type when bool is intended
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
09bcf0ff
|
2014-02-22T23:37:37
|
|
symbols: cleanup SetSymbolsField
Normalize the style and error message levels.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
35dea49b
|
2014-02-22T23:20:04
|
|
symbols: fix possible use of uninitialized value
Nothing bad can come out of it, but for some reason this error didn't
return early (inherited from xkbcomp).
Also promote the log message to an error, as it clearly is.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
5bd273a7
|
2012-11-27T10:42:15
|
|
vmod: bring back support for direct vmod -> real mod mapping
This brings back the functionality that was removed in
b9c87eb710ba4a86455601ca8c5a516b25e20366. Though it is not used in
xkeyboard-config, from our current perspective it can be quite useful to
be able to set the mappings directly, thus sidestepping the ugly and
legacy-ridden modifier_map statement.
Here's an example of how to get rid of modifier_map statements (though
that would break core-X11 applications, since they must have the
mappings through keysyms):
virtual_modifiers NumLock = Mod2;
virtual_modifiers Alt = Mod1;
// Would be nice to map these to Alt, but that would be
// incompatible with xkbcomp and somewhat complicated
virtual_modifiers LAlt = Mod1;
virtual_modifiers RAlt = Mod1;
virtual_modifiers LevelThree = Mod5;
virtual_modifiers RControl = Control;
virtual_modifiers LControl = Control;
virtual_modifiers Super = Mod4;
virtual_modifiers Meta = Mod1;
virtual_modifiers Hyper = Mod4;
virtual_modifiers AltGr = Mod5;
virtual_modifiers LShift = Shift;
virtual_modifiers RShift = Shift;
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
71a25931
|
2014-02-09T17:18:08
|
|
symbols: steal keys and modmaps when merging if possible
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
769b91c5
|
2014-02-08T15:30:05
|
|
Use (1u << idx) instead of (1 << idx) where appropriate
It doesn't matter (I think), since the implicit conversion doesn't have
any effect (e.g. sign-extension). But it's better to be aware of the
type.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
893f0130
|
2014-02-08T00:18:32
|
|
symbols: reduce some loop iterators scope
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
31430670
|
2014-01-11T16:40:42
|
|
Fix some cppcheck warnings
Someone was nice enough to run this for us:
ftp://ftp.sunet.se/pub/Linux/distributions/Debian/debian/pool/main/libx/libxkbcommon/libxkbcommon_0.3.1.orig.tar.gz
[libxkbcommon-0.3.1/src/keymap.c:86]: (style) The scope of the variable 'j' can be reduced.
[libxkbcommon-0.3.1/src/keymap.c:87]: (style) The scope of the variable 'key' can be reduced.
[libxkbcommon-0.3.1/src/keysym-utf.c:843]: (style) The scope of the variable 'mid' can be reduced.
[libxkbcommon-0.3.1/src/state.c:992]: (style) The scope of the variable 'str' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/action.c:467]: (style) The scope of the variable 'absolute' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:468]: (style) The scope of the variable 'consumed' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:862]: (style) The scope of the variable 'mlvo' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:863]: (style) The scope of the variable 'kccgst' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:865]: (style) The scope of the variable 'match_type' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/symbols.c:753]: (style) The scope of the variable 'toAct' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/symbols.c:1573]: (style) The scope of the variable 'key' can be reduced.
[libxkbcommon-0.3.1/test/common.c:80]: (warning) %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'.
[libxkbcommon-0.3.1/test/interactive.c:358]: (style) The scope of the variable 'nevs' can be reduced.
[libxkbcommon-0.3.1/test/interactive.c:236]: (style) Checking if unsigned variable 'nsyms' is less than zero.
[libxkbcommon-0.3.1/test/interactive.c:226]: (style) Unused variable: unicode
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
972395b8
|
2013-12-01T12:08:47
|
|
expr: split expression types and allocate them separately
Currently, we have one ExprDef type, which contains a tagged union with
the value of all expression types. Turns out, this union is quite
wasteful memory-wise. Instead, create separate types for all expressions
(e.g ExprBinary, ExprInteger) which embed the common fields
(ExprCommon), and malloc them per their size; ExprDef then becomes a
union of all these types, but is just used as a generic pointer.
[Instead of making ExprDef a union, another option is to use
ExprCommon as the generic pointer type and then do up-castings, like we
do with ParseCommon. But this makes the code much uglier.]
The diff is mostly straightforward mechanical adaptations. It could have
been much smaller with the help of C11 anonymous structs (which were
previously a gnu extension). This will have saved all of the 'op' ->
'expr->op', etc changes. But if we can be a bit more portable for a
little effort, we should.
Before (./test/rulescomp, x86 32 bit, -O2):
==12974== total heap usage: 145,217 allocs, 145,217 frees, 10,476,238 bytes allocated
After:
==11145== total heap usage: 145,217 allocs, 145,217 frees, 8,270,358 bytes allocated
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
068016e4
|
2013-12-01T10:45:52
|
|
parser, symbols: drop unnecessary casts
It's casted into ExprDef and then uncasted for no reason.
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>
|
|
1651e5af
|
2013-11-27T13:12:19
|
|
symbols: modernize LookupKeysym
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
64b8da4b
|
2013-11-27T12:52:20
|
|
symbols: rename info.modMaps -> modmaps
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
1e52bf79
|
2013-10-03T10:02:49
|
|
symbols: fix use of uninitialized variable
'tmp' is stack allocated so tmp->merge is used uninitialized by
AddModMapEntry(). The value doesn't matter much, but it used to
make some modmap merging decision (which doesn't have many
conflicts usually).
Bug inherited from xkbcomp.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
869c9b58
|
2013-08-13T09:57:07
|
|
xkbcomp: improve a few log messages
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
e731b251
|
2013-08-01T20:24:27
|
|
xkbcomp: handle empty keymaps
We should handle empty xkb_keycode and xkb_symbol sections, since
xkbcomp handles them, and apparently XQuartz uses it. There are also
files for it in xkeyboard-config (rules=base model=empty layout=empty,
which translate to keycodes/empty and symbols/empty).
https://bugs.freedesktop.org/show_bug.cgi?id=67654
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
9e801ff7
|
2013-07-21T17:01:20
|
|
ctx: adapt to the len-aware atom functions
xkb_atom_intern now takes a len parameter. Turns out though that almost
all of our xkb_atom_intern calls are called on string literals, the
length of which we know statically. So we add a macro to micro-optimize
this case.
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>
|
|
6a39a065
|
2013-03-04T18:35:56
|
|
Fix pointer style nit
(I really dislike this one for some reason..)
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
64c00262
|
2013-03-04T14:15:32
|
|
symbols: remove file_id
See previous commits.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
71eb033e
|
2013-03-03T21:35:43
|
|
Move a couple of general keymap functions from keycodes.c
To get a key by name and resolve an alias - this makes sense for
everyone.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
614f60e3
|
2013-03-03T00:11:27
|
|
xkbcomp: handle XKB file include's better
The 'merge_mode' situation is quite messy, and we've introduced a
regression compared to original xkbcomp: when handling a composite
include statement, such as
replace "foo(bar)+baz(bla)|doo:dee"
and merging the entire resulting *Info back into the including *Info,
we actually use the merge mode that is set by the last part (here it is
"augment" because of the '|'), when we should be using the one set for
the whole statement (here "replace").
We also take the opportunity to clean up a bit.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
a46e4cc1
|
2013-02-25T00:19:51
|
|
Fix dead assignments
"Value stored to 'stmt' is never read"
"Value stored to 'grp_to_use' is never read"
And change 'grp' to 'group' if we're here.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
b5c1b1d2
|
2013-02-07T23:28:18
|
|
symbols: make it clear which 'dflt' is meant
A bit easier at a glance. Also, vowels are cool, so just say 'default'.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
164cec66
|
2013-02-19T11:10:23
|
|
symbols: fix bad 'merge' assignment
Bug introduced in 2a5b0c9dc1ad1488ecc6b139fd70e464eb687da6, was causing
some keys to be merged incorrectly.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
f76859bc
|
2012-10-23T09:58:11
|
|
keymap: use plain array for keymap->group_names
Again it is not resized.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
714e95e1
|
2012-10-18T22:51:10
|
|
Contextualize GetBuffer()
Instead storing the buffer in a non-thread-safe static array, we move it
to the context.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
7b3bd11f
|
2012-10-16T16:05:34
|
|
Add xkb_keysym_from_name() flags argument for case-insensitive search
This adds a flags argument to xkb_keysym_from_name() so we can perform a
case-insensitive search. This should really be supported as many keysyms
have really weird capitalization-rules.
However, as this may produce conflicts, users must be warned to only use
this for fallback paths or error-recovery. This is also the reason why the
internal XKB parsers still use the case-sensitive search.
This also adds some test-cases so the expected results are really
produced. The binary-size does _not_ change with this patch. However,
case-sensitive search may be slightly slower with this patch. But this is
barely measurable.
[ran: use bool instead of int for icase, add a recommendation to the
doc, and test a couple "thorny" cases.]
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
|
|
bdea377c
|
2012-10-10T17:30:15
|
|
Rename XKB_NUM_GROUPS to XKB_MAX_GROUPS
This is a more appropriate name now.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
fcceeeaf
|
2012-10-06T21:26:01
|
|
symbols: refactor AddModMapEntry
It really asks for it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
a1124b59
|
2012-10-06T17:42:21
|
|
expr: unify the real and virtual modifier functions
This again pushes the mod type annotation to the original call site, to
make it easier to grep to see where the real/virtual distinction
matters.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
39232e6d
|
2012-10-06T17:21:09
|
|
Remove now-unneeded mod type annotations
Most of the mod type annotations can now be changed to MOD_BOTH, because
if you pass a mask which can only contain real mods in the first place to
e.g. ModMaskText, then MOD_REAL and MOD_BOTH will give the same result.
In the cases where MOD_BOTH is only ever the argument, we just remove
it. What's left is where it really "matters".
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
9ebd2f67
|
2012-10-06T14:34:17
|
|
text: explicitly take mod_type in mod functions
This essentially "tags" each invocation of the functions with the
modifier type of the argument, which allows for easy grepping for them
(with the aim being, to remove anything but MOD_BOTH).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
424de613
|
2012-10-05T22:46:21
|
|
Keep real and virtual mods in the same table in the keymap
We change the keymap->vmods array into keymap->mods, and change it's
member type from struct xkb_vmod to struct xkb_mod. This table now
includes the real modifiers in the first 8 places. To distinguish
between them, we add an enum mod_type to struct xkb_mod.
Besides being a more reasonable approach, this enables us to share
some code later, remove XKB_NUM_CORE_MODS (though the 0xff mask still
appears in a few places), and prepares us to flat out remove the
distinction in the future. This commit just does the conversion.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
6974e1f9
|
2012-10-05T21:40:49
|
|
expr: don't expose LookupModIndex
The Lookup* functions should remain a private implementation detail of
the expr.c file.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
aed3140e
|
2012-10-05T21:06:34
|
|
Remove VModInfo for now
VModInfo currently is only used to track which virtual modifiers were
declared in the file which owns the VModInfo. This, in turn, is only
used in ResolveVirtualModifier, which in turn is only used to resolve
the virtualModifier field in an interpret statement (compat.c). In other
words, it is used to ensure that interprets can only use a vmod which
was declared in the same map.
We remove this now, because it doesn't do much and distracts from other
changes; we will later re-add it properly. Specificly, we will make it
so that virtual modifiers are not the exception in that they modify the
keymap directly, instead of keeping the changes in some *Info struct and
commiting them to the keymap at the end of the compilation. (This is bad
because if a vmod is added to the keymap, and then the compilation of
this specific file fails, the change sticks around nonetheless).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
1f4009d4
|
2012-10-04T19:44:47
|
|
vmod: remove merge argument from HandleVModDef
It's unused and unneeded.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
1005b320
|
2012-10-05T22:07:04
|
|
Don't use shifted virtual modifier masks
Modifier masks can be confusing in some places. For example,
key->vmodmap only contains virtual modifiers, where the first is in
position 0, the second in 1 etc., while normally in a xkb_mod_mask_t the
virtual modifiers start from the 8th (XKB_NUM_CORE_MODS) position. This
happens in some other places as well.
Change all of the masks to be in the usual real+virtual format, and when
we need to access e.g. keymap->vmods we just adjust by
XKB_NUM_CORE_MODS. (This also goes for indexes, e.g.
interpret->virtual_modifier).
This makes this stuff easier to reason about.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
a75989b9
|
2012-10-04T12:39:22
|
|
Omit struct '_Name' from non-recursive struct typedefs
Just a pet peeve.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
fe1faa14
|
2012-10-03T20:08:13
|
|
Use our types instead of int/uint32_t in a few places
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
3b389b15
|
2012-09-27T18:49:13
|
|
Don't limit key names to 4 characters
Currently you can't give a key in xkb_keycodes a name of more than
XKB_KEY_NAME_LENGTH (= 4) chars. This is a pretty annoying and arbitrary
limitation; it leads to names such as <RTSH>, <COMP>, <PRSC>, <KPAD>
etc. which may be hard to decipher, and makes it impossible to give
more standard names (e.g. from linux/input.h) to keycodes.
The purpose of this, as far as I can tell, was to save memory and to
allow encoding a key name directly to a 32 bit value (unsigned long it
was).
We remove this limitation by just storing the names as atoms; this lifts
the limit, allows for easy comparison like the unsigned long thing, and
doesn't use more memory than previous solution. It also relieves us from
doing all of the annoying conversions to/from long.
This has a large diffstat only because KeyNameText, which is used a lot,
now needs to take the context in order to resolve the atom.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
29a8b1ce
|
2012-09-26T10:28:52
|
|
Fix size_t vs. %d warning
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
cfa6d25c
|
2012-09-25T11:49:23
|
|
symbols: get rid of autoType
The autoType variable is supposed to tell us whether the type was
explicitly specified by the user or was detected automatically according
to the keysyms. It then allows us to know whether to prints the type
when we dump the keymap to a string or not.
Right now it is not always set when we find an automatic type, according
to some apparently legacy rules. We change it to simply this: type
computed automatically? -> don't print.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
76478418
|
2012-09-25T11:35:59
|
|
symbols: separate type-finding logic from CopySymbolsDef
It's easier to follow this in isolation. Besides, previously the error
reporting wasn't done very well.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
5d265926
|
2012-09-24T14:57:30
|
|
keymap: remove some more unneeded macros
It clearer to just access the needed data directly.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
c955f8e2
|
2012-09-24T14:41:09
|
|
keymap: store a pointer to the type in xkb_group instead of index
Gets rid of some more unneeded indirection, including the XkbKeyType
macro.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
01b00d75
|
2012-09-24T12:11:31
|
|
keymap, symbols: improve xkb_key memory layout
Add struct xkb_group and xkb_level for use in xkb_key, to mirror how
it's done in KeyInfo, GroupInfo, LevelInfo in symbols.c. This
corresponds more nicely to the logical data layout (i.e. a key has
groups which have levels), and also removes a lot of copying and ugly
code due to the index indirections and separate arrays which were used
before.
This uses more memory in some places (e.g. we alloc an action for every
level even if the key doesn't have any) but less in other places (e.g.
we no longer have to pad each group to ->width levels). The numbers say
we use less overall.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
e44cd2e9
|
2012-09-24T10:55:20
|
|
symbols: move keysyms into LevelInfo
Instead of maintaining a syms array in the GroupInfo + sym_index's in
the levels. This simplifies the code somewhat.
In order not to alloc for every level instead of every group, we only do
it if the level has more than one keysym (with a union). Since for now
this is a special case, it actually works out better memory-wise.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
eaf95152
|
2012-09-24T10:16:09
|
|
symbols: fix index-out-of-bounds in FindAutomaticType
If we enter this branch, we have 3 <= width <= 4, so if the width is 3
than syms[3] is out of bounds.
Happily inherited from xkbcomp.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
504853de
|
2012-09-24T09:14:35
|
|
symbols: remove unneeded optimization
The levels will be resized to the number of levels of the type anyway,
so removing useless levels from the end here is unneeded.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
d941bc0c
|
2012-09-23T22:12:43
|
|
keymap, symbols: use darray for num_groups
Instead of using a static array of size XKB_NUM_GROUPS, because we want
to get rid of this limit.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
6d97d0ce
|
2012-09-23T20:38:25
|
|
symbols: rename SymbolsInfo groupNames to group_names
Just to match the matching field in the keymap.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
7a90f9e2
|
2012-09-23T20:36:01
|
|
keymap: don't use XKB_NUM_GROUPS for key->kt_index
One unneeded XKB_NUM_GROUPS less.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
79bbf6f7
|
2012-09-23T21:15:34
|
|
symbols: avoid possible access-out-of-bound due to explicit_group
The code that handles group name statements currently does this:
info->group_names[grp - 1 + info->explicit_group] = name;
Other than the fact that this addition makes no sense, it actually can
reach out of the bounds of the array (which is of size XKB_NUM_GROUPS)
in the (non-realistic) case where (grp - 1) is not 0 (i.e. the statement
is not name[Group1] = "foo").
We also change explicit_group to be XKB_LAYOUT_INVALID if not set
otherwise, instead of initializing it to 0; this is clearer and if
someone happens to write 'us:1' for some reason, it will discard the
other groups in the file as it should.
This entire explicit_group thing was clearly bolted on as an
afterthought.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
0dd40125
|
2012-09-22T10:58:00
|
|
API: add _context prefix to log-related functions
This is to follow the general scheme set by all of the other API
functions.
Since no one is using these functions yet, we don't (actually better
not) add the old names to xkbcommon-compat.h.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
428c6f31
|
2012-09-22T02:05:48
|
|
symbols: convert KeyInfo->groups to darray
Before it was a static array of size XKB_NUM_GROUPS.
The previous cleanups made this transition a bit easier. This is a
first step for removing the XKB_NUM_GROUPS hardcoded limit; but for now
we still check that the groups are < XKB_NUM_GROUPS (e.g. in
ResolveGroup and GetGroupIndex) until the keymap, etc. is worked out as
well.
This also makes us alloc quite a bit less (this is just rulescomp):
Before:
==51999== total heap usage: 291,474 allocs, 291,474 frees, 21,458,334 bytes allocated
After:
==31394== total heap usage: 293,595 allocs, 293,595 frees, 18,150,110 bytes allocated
This is because most rmlvo's don't use the full 4 layouts that KeyInfo
had always alloced statically before.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
f671ce07
|
2012-09-22T02:36:05
|
|
symbols: fix memleak from default KeyInfo
If the default KeyInfo gets any keysyms or actions, it needs to be
free'd.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
a12b5f62
|
2012-09-22T01:30:01
|
|
symbols: disallow changing global defaults from within a key statement
Pretty much like e5fdbcbb9943e9fe, again it isn't used.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
b70abcaf
|
2012-09-21T21:39:15
|
|
symbols: fold PrepareKeyDef into CopySymbolsDef
The function is big enough already but it's nicer to read sequentially.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
a8b932a0
|
2012-09-21T12:23:56
|
|
symbols: remove useless identical groups optimization
What this code does is, in case someone compile a keymap like -layout
'us,us,us' then only one group would be created. If there is anything
which differentiates between any of the groups (e.g. a variant, another
layout), then this is not done.
This is pretty obscure, only saves a few kbytes in the final keymap, and
if the user asked for it, why not let her?
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
95b23448
|
2012-09-21T11:54:35
|
|
symbols: avoid reverse iteration in PrepareKeyDef
No need for that.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
fcd20290
|
2012-09-21T14:44:17
|
|
Don't use xkbcommon-compat names in internal code
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
9aee332e
|
2012-09-18T17:31:55
|
|
Fix a couple of mistakes from previous commits
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
ac872bdf
|
2012-09-17T14:24:38
|
|
symbols: fix buffer overflow with illegal explicit group
Trying ''./test/interactive -l us:5' causes us to crash.
The <layout>:<N> syntax says to put this layout at the N'th level.
However the code (inherited from xkbcomp) doesn't check that the group
is valid, and then happily indexes keyi->groups with it, which has a
static size of XKB_NUM_GROUPS (the SetExplicitGroup function assumes the
index is valid). So any value a user might put there > 4 makes nice
things happen.
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>
|
|
c53122cb
|
2012-09-14T21:53:27
|
|
symbols: remove useless grow_alloc of keys array
This just does a big, mostly too big, allocation to save about a dozen
malloc calls. Remove it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
96c21e15
|
2012-09-14T00:21:54
|
|
Clean up Init/Clear functions
- The Clear* functions should just free the memory associated with the
object. If the object is used again, it is Init'd again.
- s/Free/Clear if the actual pointer is not free'd.
- Zeroise object in Init and only initialize non-zero fields.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
7b5a1dd5
|
2012-09-13T21:06:36
|
|
symbols: refactor CoypSymbolsDef
To make it easier to follow.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
4c16b39f
|
2012-09-13T21:06:10
|
|
symbols: FindAutomaticType only needs the context
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
dd6124ca
|
2012-09-13T20:59:27
|
|
symbols: store actions from symbols in the right offset
This regression was introduced in 93ce9c7d4f7. This meant that actions
specified inside key {} statments were always going to the first group.
But actions are almost never specified in xkb_symbols so this wasn't
noticed.
Signed-off-by: Ran Benita <ran234@gmail.com>
|