|
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`.
|
|
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>
|
|
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>
|
|
6b1cdee1
|
2014-04-22T11:47:23
|
|
keymap: add and use xkb_mods_{foreach,enumerate}()
To iterate over an xkb_mod_set. Slightly nicer interface and makes
transitioning from darray easier.
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>
|
|
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>
|
|
ca3170ad
|
2013-02-08T13:09:33
|
|
Add struct xkb_mod_set
The only thing that the compilation phase needs the keymap for currently
is for access to the modifier information (it also modifies it in
place!). We want to only pass along the neccessary information, to make
it more tractable and testable, so instead of passing the entire keymap
we add a new 'mod_set' object and pass a (const) reference to that.
The new object is just the old array of 'struct xkb_mod'.
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>
|
|
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>
|
|
9a2ce2a5
|
2012-10-05T20:17:54
|
|
vmod: don't allow to add a vmod with the name of a real mod
Otherwise strange thing might ensue.
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>
|
|
dd29b14e
|
2012-10-03T12:57:53
|
|
Remove the XKB_NUM_VIRTUAL_MODIFIERS limit
Turn the virtual modifiers arrays in the keymap to a single darray,
which doesn't use this limit. The number of virtual modifiers is still
limited by the size of xkb_mod_mask_t, so we make sure not to go over
that.
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>
|
|
fcd20290
|
2012-09-21T14:44:17
|
|
Don't use xkbcommon-compat names in internal code
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>
|
|
b04d896a
|
2012-08-21T12:48:20
|
|
kbproto unentanglement: XkbNumVirtualMods
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
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>
|
|
3d305bd0
|
2012-08-30T13:49:23
|
|
vmod: remove outdated comments
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>
|
|
f410622b
|
2012-08-15T22:07:37
|
|
vmod: remove support for resolving integer to virtual modifier
This is only relevant to the virtualModifier= statement in interpret
statements in xkb_compat. The current code allows to write e.g.
virtualModifier = 4
to get the virtual modifier whose index happens to be 4 (possibly
declared in other files or sections, i.e. xkb_types). Doing this is
undeterministic, will break without notice, and not used anywhere.
Don't allow it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
b9c87eb7
|
2012-08-14T17:11:16
|
|
vmod: remove support for direct vmod -> real mod mapping
The current code supports statements such as:
virtual_modifiers NumLock = Mod2;
This would set the mapping from the NumLock vmod to the Mod2 real mod
directly, without going through the virtualModifier field in an
interpret statement (in xkb_compat) or vmods field in a key statement
(in xkb_symbols).
This is undocumented, unused and complicates things, so remove it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
ab1566cd
|
2012-08-28T11:11:40
|
|
vmod: remove useless keymap initialization
keymap->vmods is not touched until UpdateModifiersFromCompat,
where it initialized and used.
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>
|
|
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>
|
|
b0b11c4e
|
2012-08-02T00:29:07
|
|
types: don't use canonical/required types
Xkb required every keymap to have at least the four following canonical
types: ONE_LEVEL, TWO_LEVEL, ALPHABETIC, KEYPAD. This is specified in
e.g. the kbproto spec and XkbKeyTypesForCoreSymbols(3) man page.
If these types are not specified in the keymap, the code specifically
checks for them and adds them to the 4 first places in the types array,
such that they exist in every keymap. These are also the types (along
with some non-required 4-level ones) that are automatically assigned to
keys which do not explicitly declare a type (see FindAutomaticType in
symbols.c, this commit doesn't touch these heuristics, whcih are also not
very nice but necessary).
The xkeyboard-config does not rely on the builtin xkbcomp definitions of
these types and does specify them explicitly, in types/basic and
types/numpad, which are virtually always included.
This commit removes the special behavior:
- The code is ugly and makes keytypes.c harder to read.
- The code practically never gets run - everyone who uses
xkeyboard-config or a keymap based upon it (i.e. everyone) doesn't need
it. So it doesn't get tested.
- It mixes policy with implementation for not very good reasons, it
seems mostly for default compatibility with X11 core.
- And of course we don't need to remain compatible with Xkb ABI neither.
Instead, if we read a keymap with no types specified at all, we simply
assign all keys a default one-level type (like ONE_LEVEL), and issue
plenty of warnings to make it clear (with verbosity >= 3). Note that
this default can actually be changed from within the keymap, by writing
something like
type.modifier = Shift
type.whatever_field = value
in the top level of the xkb_types section. (This functionality is
completely unused as well today, BTW, but makes some sense).
This change means that if someone writes a keymap from scratch and
doesn't add say ALPHABETIC, then something like <AE11> = { [ q Q ]; }; will
ignore the second level. But as stated above this should never happen.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
09dac54b
|
2012-08-01T21:31:36
|
|
vmod: remove unused fields
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
41d9afc5
|
2012-07-27T15:31:03
|
|
Remove ExprResult
Convert the IdentLookup typedef away from ExprResult, which drags along
everything else. This should also make all of the conversions explicit.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
38614c88
|
2012-07-24T17:21:29
|
|
expr: drop ExprResult from ResolveMask
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
2e4933cd
|
2012-07-24T10:39:15
|
|
expr: drop ExprResult from ResolveInteger
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
724f62c8
|
2012-07-25T17:29:08
|
|
Convert defines to enums in xkbcomp.h
For statement / expression types.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
89723b7c
|
2012-07-24T19:54:14
|
|
utils: add/replace string equality macros
It's more tidy and less error prone, since we use strcasecmp == 0 a lot.
We replace strcmp == 0 by streq, strcasecmp == 0 by istreq,
uStrCasePrefix by istreq_prefix and uDupString by strdup_safe.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
4f843c81
|
2012-07-24T13:24:59
|
|
Drop Xkbc prefix of text functions
Not really needed and inconsistent.
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>
|
|
112cccb1
|
2012-07-23T16:03:34
|
|
Some atom related optimizations
We often get a strdup'd string, just to pass it over the atom_intern and
then immediately free it. But atom_intern then strdup's it again (if
it's not interned already); so instead we can have the interning "steal"
the memory instead of allocing a new one and freeing the old one. This
is done by a new xkb_atom_steal function.
It also turns out, that every time we strdup an atom, we don't actually
modify it afterwards. Since we are guaranteed that the atom table will
live as long as the context, we can just use xkb_atom_text instead. This
removes a some more dynamic allocations.
For this change we had to remove the ability to append two strings, e.g.
"foo" + "bar" -> "foobar"
which is only possible with string literals. This is unused and quite
useless for our purposes.
xkb_atom_strdup is left unused, as it may still be useful.
Running rulescomp in valgrind, Before:
==7907== total heap usage: 173,698 allocs, 173,698 frees, 9,775,973 bytes allocated
After:
==6348== total heap usage: 168,403 allocs, 168,403 frees, 9,732,648 bytes allocated
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
544a83e6
|
2012-07-21T15:27:09
|
|
vmod: use new log functions
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
1313af8f
|
2012-07-15T01:31:34
|
|
Get rid of xkb_key_names
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
3de9d874
|
2012-07-15T00:26:28
|
|
Get rid of xkb_server_map
Same as xkb_client_map which was removed before.
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>
|
|
213dcf68
|
2012-06-29T17:31:10
|
|
Use enum for merge mode
The merge mode shows up in a lot of functions, so it's useful to give it
a distinct type.
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.]
|
|
cdd2906d
|
2012-05-09T13:50:05
|
|
Make the context available for XkbcAtomText
And rename the function to xkb_atom_text.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb -> keymap.]
|
|
8d680e80
|
2012-05-09T12:01:03
|
|
Make the context available for XkbcAtomGetString
In preparation of contextualizing atom handling.
Since we touch every function call, we also rename the function to
xkb_atom_strdup to match xkb_atom_intern, and be more descriptive.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb -> keymap.]
|
|
c117318f
|
2012-05-09T11:47:20
|
|
Make the context available to xkb_intern_atom
In preparation of contextualizing the atom table.
Since we touch every function call, also rename the function to
xkb_atom_intern, to match better with the rest (which will also be
renamed).
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Fixed for 'xkb' -> 'keymap'.]
|
|
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>
|
|
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>
|
|
62a75dc1
|
2012-04-10T23:08:49
|
|
Remove unused stuff from XKBcommonint.h
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
a641a185
|
2012-04-06T03:38:55
|
|
Use stdbool.h
'Cause defining your own True and False is so 1990's.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Fixed for xkb_desc -> xkb_keymap changes.]
|
|
ef88c7ef
|
2012-04-03T15:14:16
|
|
Rename xkb_desc to xkb_keymap
struct xkb_desc was just a hangover from the old XkbDescRec, which isn't
a very descriptive name.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
84ec6b61
|
2012-04-01T16:51:48
|
|
Add a NULL check before before strcmp'ing
The names array can have NULL entries for some virtual modifier indexes.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
fb606b06
|
2012-04-01T17:07:56
|
|
Avoid use of partly initialized VModInfo in error path
Such as:
Compiling path: ./test/data/bad.xkb mapName:
==1300== Conditional jump or move depends on uninitialised value(s)
==1300== at 0x4E46166: HandleVModDef (vmod.c:90)
==1300== by 0x4E3FEC9: HandleKeyTypesFile (keytypes.c:1035)
==1300== by 0x4E3FBE1: HandleIncludeKeyTypes.constprop.11 (keytypes.c:387)
==1300== by 0x4E401DD: HandleKeyTypesFile (keytypes.c:1022)
==1300== by 0x4E3FBE1: HandleIncludeKeyTypes.constprop.11 (keytypes.c:387)
==1300== by 0x4E401DD: HandleKeyTypesFile (keytypes.c:1022)
==1300== by 0x4E4026F: CompileKeyTypes (keytypes.c:1150)
==1300== by 0x4E3DF9B: CompileKeymap (keymap.c:169)
==1300== by 0x4E465E9: compile_keymap (xkbcomp.c:205)
==1300== by 0x4E46BE4: xkb_compile_keymap_from_file (xkbcomp.c:290)
==1300== by 0x400B37: test_file (filecomp.c:47)
==1300== by 0x4008E3: main (filecomp.c:90)
==1300== Uninitialised value was created by a stack allocation
==1300== at 0x4E3FB3F: HandleIncludeKeyTypes.constprop.11 (keytypes.c:366)
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
0480f427
|
2012-03-23T23:28:24
|
|
Remove useless stuff from utils
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: fixed conflicts from strcasecmp, added includes to make
filecomp build again]
|
|
a0e756fd
|
2012-03-09T19:09:25
|
|
Introduce xkb_atom_t type
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
731e5c40
|
2012-03-09T18:53:47
|
|
Stringify public name types
Ensure that all names under xkb_desc are strings, rather than atoms.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
b28823cc
|
2012-03-09T16:04:00
|
|
Remove KcCGST names from the map
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
eb738b13
|
2012-03-02T17:40:19
|
|
Constify global tables
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
a3e40917
|
2012-03-01T23:43:51
|
|
Remove return's at the end of void functions
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
f278cea1
|
2012-02-29T20:25:11
|
|
Remove all uses of the register keyword
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
a0dd0526
|
2012-02-25T11:46:12
|
|
Remove unused includes of "tokens.h"
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
43ed3ff0
|
2012-02-20T17:14:04
|
|
Switch expression resolution priv from char to void
Avoids a lot of really lame casts.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
11ea0791
|
2012-02-20T17:07:48
|
|
Invert LookupModMask/LookupVModMask order
We never want to solely lookup a virtual modifier without also looking
up core modifiers. So, rather than chaining the vmod lookup inside the
core modifier lookup, invert the ordering.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
90d86c36
|
2012-02-20T16:54:54
|
|
Remove field reference lookup support
None of the lookup functions anyone ever used supported field
references, so don't pretend we do in the API.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
91b89852
|
2012-02-20T16:24:02
|
|
Turn ExprResolveInteger into a simple wrapper
Move the bulk of ExprResolveInteger into an internal function called
ExprResolveIntegerLookup, and introduce ExprResolveInteger as a simple
wrapper which doesn't take priv/lookup arguments.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
3151ce36
|
2012-02-20T13:34:36
|
|
Remove priv arguments from ExprResolveModMask
What with them now being unused and all.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
1a6c3807
|
2012-02-15T15:58:14
|
|
vmod: Pass xkb_desc explicitly to vmod functions
Some error paths don't set info->xkb correctly, so just do like most
utility functions and pass the xkb_desc explicitly.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
a63e82be
|
2010-12-17T21:14:54
|
|
Rename XkbcInternAtom() to xkb_intern_atom() and export
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
73ca959d
|
2010-09-27T16:05:52
|
|
Dead code removal and static markup
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
9f602686
|
2010-07-01T14:35:24
|
|
Pull in enough structs and defines from XKBstr.h to only need XKB.h
We want to move away from sharing implementation structs and let libX11
and libxkbcommon use each their own set of structs.
|
|
e10e16ad
|
2010-06-30T17:20:56
|
|
Constify XkbcAtomText()
Atoms aren't mutable and this lets us put tbGetBuffer() back in the box.
|
|
47d3b396
|
2010-06-28T06:50:12
|
|
Drop CARD32 and Opaque types
|
|
7257d4c8
|
2010-06-21T14:28:34
|
|
Use CARD32 instead of Atom, move geom headers in
Use CARD32 instead of Atom/KeySym/et al to avoid type size confusion
between server and non-server code; relatedly, move the geometry headers
in from kbproto, so every non-simple type (i.e. structs containing
nothing more than basic types) is now copied into xkbcommon.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
d20bdd3b
|
2010-06-15T15:14:58
|
|
xkbcomp: vmod: Don't get and immediately intern atoms
XkbcInternAtom(XkbcAtomGetString(atom)) has to be the most spectacularly
broken antipattern I've yet seen. Just compare the atoms directly.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
6a84a34d
|
2009-04-08T07:46:25
|
|
Remove all non-public API from XKBcommon.h header
The noble intention was to expose all the new API and new generic types
in the split out kbproto headers through XKBcommon.h. It turns out that
would be a massive amount of work in the server. Someday, but first just
wedging in XkbCompileKeymap* would be good.
Most of the API is in new internal xkb*.h headers. In order to allow the
XKBcommon.h header to be used from the server, we can't pull in other
headers from kbproto since the server has its own copies. However, types
that are different (XkbDescRec, XkbAction) still have Xkbc equivalents
here, and I think they should be used in the server.
|
|
8b100fc0
|
2009-04-05T15:15:20
|
|
Add action datatypes as defined in the server
Some of the XkbAction types are defined differently in the server, so we
add those to XKBcommon.h and use them here like XkbcDescPtr. We'll have
to deal with the impedance mismatch on the client side later.
|
|
a2e59767
|
2009-04-04T12:50:27
|
|
xkbcomp: Don't say we're exiting when we're not
|
|
5c910623
|
2009-04-04T09:19:51
|
|
Remove trailing spaces in source files
|
|
a27e56b6
|
2009-03-31T07:21:20
|
|
xkbcomp: Remove duplicated macros
|
|
2671b777
|
2009-03-28T14:06:26
|
|
Add more *Text functions from xkbfile
This should cover all the usage in xkbcomp. The format arguments were
dropped except for the special case of XkbModMaskText, which needs to
write in XkbCFile format in HandleVModDef. This was just changed to a
Bool to avoid the need for the macros in XKBfile.h.
The function prefixes have been renamed to be unique from xkbfile.
|
|
39d7be43
|
2009-03-28T11:45:05
|
|
xkbcomp: Use xkbcommon allocation functions
s/XkbAlloc/XkbcAlloc/ so we don't know XKBlib.
|
|
8544cde5
|
2009-03-28T06:56:26
|
|
xkbcomp: Drop unused Display argument in Atom functions
The xkbcommon Atom implementation doesn't take Display into account.
|
|
18337008
|
2009-03-27T20:58:27
|
|
libxkbcomp: Use the internal Atom implementation
s/XkbInternAtom/XkbcInternAtom/ and s/XkbAtomGetString/XkbcAtomGetString/
|
|
4fe322aa
|
2009-03-27T20:13:22
|
|
libxkbcomp: s/XPointer/char */
Replace XPointer with its definition since we don't have the privilege
of using Xlib.h. Why this is char * and not void *, I'll never know.
|
|
37769b5a
|
2009-03-27T20:01:32
|
|
libxkbcomp: s/XkbDescPtr/XkbcDescPtr/
We need to use the keyboard description structure from XKBcommon.h since
it doesn't have the Display field.
|
|
30e01032
|
2009-03-27T19:25:14
|
|
libxkbcomp: Remove usage of client-side headers
This will surely break things. Let's see just what we need to replace.
|
|
0c1bbb05
|
2009-03-27T06:55:32
|
|
Import xkbcomp sources for CompileKeymap
A copy of the xkbcomp sources (except the frontend) have been copied in
to provide a means to compile a XkbDescPtr. This definitely doesn't
build or do the right thing yet.
|