|
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`.
|
|
|
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.
|
|
fa86433e
|
2021-03-30T07:56:09
|
|
xkbcomp: remove useless assignment
../../../src/xkbcomp/compat.c:693:16: warning: Although the value stored to
'merge' is used in the enclosing expression, the value is never actually read
from 'merge' [deadcode.DeadStores]
si.merge = merge = (def->merge == MERGE_DEFAULT ? merge : def->merge);
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
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>
|
|
|
3d43f480
|
2019-11-12T22:31:46
|
|
compat: reject interpret modifier predicate with more than one value
Given
interpret ISO_Level3_Shift+AnyOf(all,extraneous) { ... };
Previously, extraneous (and further) was ignored. Now it's rejected.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
96df3106
|
2017-06-26T17:12:29
|
|
xkbcomp: Don't crash on no-op modmask expressions
If we have an expression of the form 'l1' in an interp section, we
unconditionally try to dereference its args, even if it has none.
Signed-off-by: Daniel Stone <daniels@collabora.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>
|
|
|
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>
|
|
|
67d884ec
|
2014-06-01T15:24:10
|
|
Remove unnecessary !!(expressions)
_Bool already does that.
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>
|
|
|
9014cf8c
|
2014-04-22T13:15:21
|
|
keymap, keycodes, compat: don't use darray for LEDs
Use a static array of size XKB_MAX_LEDS instead, as in xkb_mod_set.
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>
|
|
|
bf2878d2
|
2013-02-08T15:12:35
|
|
compat: use xkb_mod_set instead of entire keymap
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>
|
|
|
659eacc9
|
2013-02-08T00:22:38
|
|
compat: separate ctx
Same as was done for types.
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>
|
|
|
a7d753e4
|
2014-02-09T17:17:13
|
|
compat: steal interps and leds when merging if possible
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
3923aa71
|
2014-02-09T11:27:34
|
|
doc: move some file comments into txt files in doc/
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>
|
|
|
dbd8b1ef
|
2013-11-30T22:25:39
|
|
expr: add 'ident' value to ExprDef union
This distinguishes between an identifier expression and a string
expression in the union.
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>
|
|
|
869c9b58
|
2013-08-13T09:57:07
|
|
xkbcomp: improve a few log messages
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
9ffe9dae
|
2013-07-21T09:48:12
|
|
keymap: don't use darray for sym_interprets
We want xkb_keymap to be easy to handle everywhere.
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>
|
|
|
4921eb74
|
2013-03-04T14:11:13
|
|
compat: remove file_id
See previous commit.
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>
|
|
|
540feef3
|
2013-03-01T13:51:13
|
|
More spelling errors
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
8cee7490
|
2013-02-17T22:18:57
|
|
Change 'indicator' to 'led' everywhere possible
The code currently uses the two names interchangeably.
Settle on 'led', because it is shorter, more recognizable, and what we
use in our API (though of course the parser still uses 'indicator').
In camel case we make it 'Led'.
We change 'xkb_indicator_map' to just 'xkb_led' and the variables of
this type are 'led'. This mimics 'xkb_key' and 'key'.
IndicatorNameInfo and LEDInfo are changed to 'LedNameInfo' and
'LedInfo', and the variables are 'ledi' (like 'keyi' etc.). This is
instead of 'ii' and 'im'.
This might make a few places a bit confusing, but less than before I
think. It's also shorter.
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>
|
|
|
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>
|
|
|
fab28da3
|
2013-02-08T16:06:35
|
|
compat: make it clear which 'dflt' is meant
Also s/dflt/default.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
6a94b122
|
2012-10-22T20:49:44
|
|
Split the mods, layout, leds parts of xkb_state_components
Note first:
This commits breaks the ABI somewhat. If an application is run against
this commit without recompiling against the updated header, these break:
- xkb_state_layout_*_is_active always retuns false.
- xkb_state_serialize_mods always returns 0.
So it might break layout switching in some applications. However,
xkbcommon-compat.h provides the necessary fixes, so recompiling should
work (though updating the application is even better).
Split the enum to its individual components, which enables us to refer
to them individually. We will use that later for reporting which
components of the state have changed after update.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
e6946ae2
|
2012-10-18T22:55:17
|
|
Remove a couple more uses of static char buffers
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>
|
|
|
eb748ab6
|
2012-10-18T21:04:27
|
|
Clean up xkb_sym_interpret a bit
First we split the LEVEL_ONE_ONLY bit off of the 'match' field, which
allows us to turn enum xkb_match_operation to a simple enum and remove
the need for MATCH_OP_MASK.
Next we rename 'act' to 'action', because we've settled on that
everywhere else.
Finally, SIMatchText is changed to not handle illegal values - it
shouldn't get any. This removes one usage of the GetBuffer hack.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
b6ddd105
|
2012-10-11T14:05:49
|
|
keymap: rename keymap->sym_interpret -> sym_interprets
This can be a bit confusing.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
e43f53a6
|
2012-10-11T14:03:03
|
|
compat: add documentation for interpret's
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
90b1984c
|
2012-10-11T12:07:43
|
|
compat: don't forget to copy XKB_MATCH_NONE interpret's
Commit a8d462e3669b1790dfad75836d5ec59e390392ef accidentally removed the
OR with XKB_MATCH_NONE. It is in fact unused though.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
9197eb0f
|
2012-10-10T19:08:01
|
|
Remove the XKB_NUM_INDICATORS limit
Use a darray instead of a static array of size 32.
We still enforce XKB_MAX_LEDS because of the size of xkb_led_mask_t.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
2ac319c5
|
2012-10-08T22:11:18
|
|
compat: fix bad interpret predicate mods "all" calculation
Commit 9984d1d03cd78eb636c75cc2bbd2d240dc1dd72f changed the type of
interpret->mods to xkb_mod_mask_t, but this bit of code assumes that the
type is uint8_t.
This code is not usually run (for example by our tests), but when it
does keymap-dump would print out all of the modifiers (including the
virtual ones) which causes recompilation of the output to fail
miserably.
https://bugs.freedesktop.org/show_bug.cgi?id=55769
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
6d74e66e
|
2012-10-06T17:53:53
|
|
Replace 0xff with MOD_REAL_MASK_ALL
To make it easier to see where it's used. The name is just to match
MOD_REAL.
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
b4b40d73
|
2012-09-12T16:54:07
|
|
Copyright updates
With Dan Nicholson's permission (via email), update his copyright and
license statements to the standard X.Org boilerplate MIT license, as
both myself and Ran have been using.
Clean up my copyright declarations (in some cases to correct ownership),
and add copyright/license statements from myself and/or Ran where
appropriate.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
2eab7efc
|
2012-09-11T12:32:18
|
|
kbproto unentanglement: XkbSI_AutoRepeat
That was the only interp flag, so just turn it into a straight boolean.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
a8d462e3
|
2012-09-11T12:28:29
|
|
kbproto unentanglement: XkbSI match flags
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
830fe671
|
2012-09-10T20:07:54
|
|
kbproto unentanglement: XkbIM_*
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
0b2506db
|
2012-09-10T19:23:16
|
|
kbproto unentanglement: action types
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
74ec4c1c
|
2012-08-21T12:47:28
|
|
kbproto unentanglement: XkbNumIndicators
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
54d1d5ed
|
2012-09-04T17:40:09
|
|
compat: make LEDInfo a wrapper around xkb_indicator_map
instead of duplicating the fields. The same is done in SymInterpInfo
which wraps xkb_sym_interpret.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
5f613988
|
2012-09-04T17:20:46
|
|
Fold keymap->indicator_names into keymap->indicators
This makes sense, since giving a name to an indicator 'activates' the
indicator_map in that index.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
af2a8b3a
|
2012-09-02T21:45:42
|
|
Unify some string tables from xkbcomp, text and keymap-dump
We move the LookupEntry struct from expr.h to text.h, along with most of
the lookup tables. This makes them available everywhere.
Looking up a value in the LookupEntry format is slower than direct index
mapping, but it allows multiple names per value (with the canonical one
being first) and "all"- and "none"-type masks. These functions are not
used anywhere efficiency matters.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
7ae0c6ba
|
2012-08-31T19:26:51
|
|
Convert rest of names in xkb_keymap back to atoms
These were kept as atoms, but since the keymap was exposed in the API,
we converted them to strings; no the keymap is no longer exposed, so we
can go back to atoms. They make the keymap smaller (at least on 64-bit
machines) and the comparisons faster.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
41472822
|
2012-08-29T15:17:00
|
|
Use XKB_MOD_INVALID instead of XkbNoModifier
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
87bfd973
|
2012-09-02T11:29:31
|
|
action: keep array of default actions, instead of list of changes
The implementation of changing the default properties of actions, e.g. a
statements such as (from test/data/compat/basic):
setMods.clearLocks= True;
latchMods.clearLocks= True;
latchMods.latchToLock= True;
works by keeping a list of ActionInfo's, each containing the neccesary
info from each statement, and then when some action comes up (e.g. in an
interpret statment) it goes through the list, and applies the relevent
ActionInfo's to the newly-constructed xkb_action.
Instead of doing this, we add a struct ActionsInfo, which contains an
array of xkb_actions, one for each type. When a default changing
statement appears, we change the action in the array; when a new action
comes up, we just copy from the array. This is simpler to figure out,
and pretty straightforward.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
db639be6
|
2012-09-03T10:23:44
|
|
keymap: optimize FindInterpsForKey a bit
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>
|
|
|
b3aced7e
|
2012-08-28T11:14:54
|
|
vmod: ClearVModInfo doesn't need the keymap
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>
|
|
|
eaa50c45
|
2012-08-15T10:10:44
|
|
xkbcomp: seperate keymap-copying code from Compile functions
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
6738d300
|
2012-09-02T19:16:34
|
|
compat: only compute 'bool report' once
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
e5fdbcbb
|
2012-09-02T11:49:43
|
|
compat: disallow changing global defaults from within an interpret
It's currently possible to write something like this:
interpret Num_Lock+Any {
virtualModifier = NumLock;
action = LockMods(modifiers=NumLock);
!indicator.allowExplicit;
};
The final statement has the same effect as writing it in the global file
scope, which changes the default indicator (which all subsequent
indicators start off as). This very strange and also unused; if someone
does it he probably expects it to affect only the local scope, and he
might then get unexpected behavior. So don't allow it.
Also, HandleInterpVar is clearly a misnomer (as it can also change
indicator defaults) so rename it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
c9466b32
|
2012-08-27T22:06:50
|
|
compat: use darray instead of list for interps
No need for a list here.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
8c6694fd
|
2012-09-02T18:51:26
|
|
compat: remove "flags" field from xkb_indicator_map
We don't set this field any more.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
6e676cb7
|
2012-08-30T18:56:24
|
|
compat: ignore "allowExplicit" in indicator statements
Using !allowExplicit sets the XkbIM_NoExplicit flag of the indicator,
which means that an XKB client cannot change the state of the indicator
using e.g. XkbSetNamedIndicator().
We do not support changing the state of an indicator; furthermore doing
it is probably only useful in conjunction with led-drives-keyboard
behavior, which we also do not support. This is because setting an
indicator without led-drives-keyboard would make the indicator and the
modifier/group it's bound to to get out of sync.
We can re-add this if we need this info.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
d573600d
|
2012-08-30T16:39:33
|
|
compat: ignore "ledDrivesKbd" in indicator statements
We don't support it, as mentioned in the README, so we should stop
processing it and print a message about it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
9de067aa
|
2012-08-27T21:31:18
|
|
compat: ignore "group" (compatibility) statements
Group compatibility statements are like the following:
group 3 = AltGr;
This currently results in:
keymap->groups[2].mask = <real mod mapped from AltGr vmod>
And we don't do any thing with this value later. The reason it exists in
XKB is to support non-XKB clients (i.e. XKB support disabled entirely in
the server), which do not know the concept of "group", and use some
modifier to distinguish between the first and second keyboard layouts
(usually with the AltGr key). We don't care about all of that, so we can
forget about it.
One artifact of this removal is that xkb_map_num_groups no longer
works, because it counted through keymap->groups (this wasn't entirely
correct BTW). Instead we add a new num_groups member to the keymap,
which just hold the maximum among the xkb_key's num_groups. This also
means we don't have to compute anything just to get the number of
groups.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
7f75502f
|
2012-08-27T13:21:03
|
|
compat: get rid of BindIndicators
Now that 1fba6189e67 removed support for binding indicator maps by index
instead of name, we can remove some more magic which happens now: if an
indicator map specifies an indicator name which was not previously
declared in a 'indicator 5 = "Caps Lock"'-like statement in
xkb_keycodes, we can just look at the next free index and assign it.
This also allows us to use a darray for the LEDInfo's instead of a list.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
02de2a3e
|
2012-08-27T12:29:57
|
|
compat: ignore "index" field in indicator statements
The current code allows to set the "index" field in an indicator
statment's body. This would bind the indicator to the specified index,
instead of by name (which was declared previously in xkb_keycodes).
Doing this is a bad idea, for the same reasons as in 3cd9704, and is
also happily not used anywhere.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
65c4a717
|
2012-08-27T11:38:44
|
|
compat: remove dead NoAutomatic code
The xkblib spec, table 7.1 (indicators), says:
XkbIM_NoAutomatic: Xkb does not automatically change the value of the
indicator based upon a change in the keyboard state,
regardless of the values for the other fields of the
indicator map.
xkbcomp (the real one) never actually implemented a way for an indicator
statement to set this flag, so it's just dead unused code. We definitely
don't want to implement it ourselves, so remove any mention of it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
16f2de8b
|
2012-08-14T16:26:30
|
|
compat: ignore "locking" field in sym interprets
This field is used in conjunction with key behaviors, which we don't
support since c1ea23da5. This is also unused in xkeyboard-config.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
4fec91cb
|
2012-08-14T15:05:56
|
|
compat: add general overview
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
79a2cc09
|
2012-08-11T11:54:05
|
|
action: convert action field type to enum
We can also hide the ActionInfo definition inside action.c.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
e9aa84f3
|
2012-08-14T15:06:11
|
|
compat: small changes
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>
|
|
|
4c34bda1
|
2012-08-10T22:38:07
|
|
action: get rid of xkb_any_action
And use union xkb_action instead. We add xkb_private_action, which is
the same as xkb_any_action, but only used where the intention is clear.
This should take care of whatever sizing changes the action struct might
have.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
87dff888
|
2012-08-10T18:14:35
|
|
Store actions inside struct xkb_key
Cuts out a lot of useless redirection and space.
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>
|
|
|
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>
|
|
|
41478b43
|
2012-08-09T01:30:22
|
|
types: don't compute effective masks here as well
After compiling all of the sections, UpdateModifiersFromCompat does all
of the vmod -> real mods translations, including types/kt_entries.
keytypes.c also has code that does that, but it's unneeded:
- Later sections don't look at their effective masks, so doing it later
is fine.
- When this code is executed, the vmods -> real mods mapping is empty
(that is set up later), so VModsToReal has no effect here.
So we can just remove it.
However UpdateModifiersFromCompat didn't update the preserve mask, so do
that.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
4bb8b6b1
|
2012-08-03T05:19:50
|
|
Remove unused vmodmask calculation
This was basically an open-coded VModsToReal, which we were using in the
line immediately below.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
8ccfee82
|
2012-08-07T08:38:20
|
|
types: use regular array for types
The current code doesn't resize it any more.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
6b75dd2d
|
2012-08-05T19:38:31
|
|
Fix virtual modifiers mask extraction
The calculations were performed incorrectly in several places,
specifically shifting by 16 instead of 8 (= XkbNumModifiers) and masking
with 0xff instead of 0xffff.
More stuff that probably never worked as intended. This also makes these
more grep-able when we remove the vmods/real_mods separation.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
b2fba730
|
2012-08-07T08:52:23
|
|
types: use regular array for map entries
This array is only initialized once.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
cead8527
|
2012-08-01T22:12:13
|
|
Replace more defines with enums
Mostly the ones used to track the fields of types/keys/leds which were
already defined.
Signed-off-by: Ran Benita <ran234@gmail.com>
|