|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
32c19f4b
|
2012-09-27T21:30:29
|
|
keymap-dump: make it look better with long key names
Not worth messing around with too much, just make it legible.
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>
|
|
|
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>
|
|
|
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>
|
|
|
9a18b872
|
2012-09-23T17:52:51
|
|
Add format argument to xkb_keymap_get_as_string
This function really needs a format argument, for symmetry with the
keymap creation functions. If we add new formats, we will almost
certainly want to add support for serializing it into a string. It would
also allow to convert from one format to another, etc.
The in the common case, the user would just want to use the format she
used to create the keymap; for that we add a special
XKB_KEYMAP_USE_ORIGINAL_FORMAT value, which will do that (it is defined
to -1 outside of the enum because I have a feeling we might want to use
0 for something else). To support this we need to keep the format inside
the keymap. While we're at it we also initialize keymap flags properly.
This changes the API, but the old xkb_map_get_as_string name works as
expected so this is the best time to do this.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
be3cbc99
|
2012-09-22T10:21:22
|
|
keymap: remove XkbKeyGetKeycode
Because we keep the keycode inside the xkb_key now.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
bbaa11c6
|
2012-09-21T14:58:31
|
|
Rename map.{c,h} to keymap.{c,h}
Seeing as we don't like "map" anymore.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
fcd20290
|
2012-09-21T14:44:17
|
|
Don't use xkbcommon-compat names in internal code
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
bf194080
|
2012-09-19T16:19:57
|
|
Promote keymap enumeration API to public
Rename the functions to get keysyms by key/layout/level to fit with the
recent public API renames, and expose them.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
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>
|
|
|
4b69d6f7
|
2012-09-15T02:09:34
|
|
keycodes: ignore explicit minimum/maximum statements
These statements are pretty pointless for us; we don't restrict keycodes
like X does, and if someone writes e.g. maximum = 255 but only has 100
keys, we currently happily alloc all those empty keys. xkbcomp already
handles the case when these statements aren't given, and uses a computed
min/max instead. We should just always use that.
(Of course since keycodes/evdev currently uses almost all of the
keycodes in the range it declares, including 255, this doesn't save any
memory for the common user right now).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
c2570d51
|
2012-09-14T11:17:30
|
|
state, map: constify references to xkb_key
Makes it clear that we treat the keys as immutible values in these
files.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
a9fa3739
|
2012-09-12T16:39:54
|
|
keymap-dump: don't write spaces between multiple-syms-per-level
This can get a bit unwieldy.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
e60e9523
|
2012-09-11T12:35:24
|
|
kbproto unentanglement: XkbExplicit*Mask
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>
|
|
|
ed9fd5be
|
2012-09-11T12:20:21
|
|
kbproto unentanglement: control actions
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
32bf4053
|
2012-09-10T20:44:52
|
|
kbproto unentanglement: Xkb{Wrap,Clamp,Redirect}IntoRange
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
461f8a76
|
2012-09-10T20:40:05
|
|
actions: Remove PointerDefault affect field
This was always set to affect the default button, so no need for it.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
70c775f6
|
2012-09-10T20:38:46
|
|
kbproto unentanglement: action 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>
|
|
|
314965b1
|
2012-08-21T14:40:51
|
|
Remove deprecated actions
We didn't do anything with ISO_Lock, ActionMessage, RedirectKey, and the
device-specifying variants of the pointer actions, so remove those.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
b04d896a
|
2012-08-21T12:48:20
|
|
kbproto unentanglement: XkbNumVirtualMods
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>
|
|
|
4b8ceae9
|
2012-08-21T12:45:03
|
|
kbproto untanglement: XkbKbdNumGroups
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
600caac3
|
2012-08-10T22:06:12
|
|
Remove XkbKeyTypeIndex and widen index type
We don't need the macro, and using char for the kt_index is imaginably
too small.
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>
|
|
|
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>
|
|
|
0f1ca360
|
2012-08-08T20:47:51
|
|
keymap-dump: use VModMaskText
The difference between the two are irrelevant here.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
d327d3e2
|
2012-08-07T11:40:07
|
|
types: store atoms instead of strings for level and type names
We don't use these strings much, so storing them in the manner they
were compiled saves some copying and space.
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>
|
|
|
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>
|
|
|
a681c624
|
2012-08-07T08:17:26
|
|
types: remove DeleteLevel1MapEntries
If there is no map entry for some modifier combination, the default is
to use level 1. The removed code is an optimization to save some space
by removing these entries. But it doesn't actually save any space, and
did not in fact remove all level 1 entries (it walks the array while
modifying it so there's an off-by-one error).
We can instead keep them in the types but just not print them in
keymap-dump.c, to get about the same behavior.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
233d85c4
|
2012-08-06T21:31:17
|
|
types: move preserve directly into xkb_kt_map_entry
Currently each xkb_key_type has a preserve array, which is only allocated
if a preserve[] statement is specified in the type. In this case each map
entry has an element in the array.
The space savings are negligible; put this field where it logically
belongs.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
59d947c9
|
2012-08-05T19:24:44
|
|
Add and use xkb_level_index_t
Several types are used over the code for shift levels; better to use
just one.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
7c7e4341
|
2012-08-01T11:25:34
|
|
Use only one set of core mod name-to-index functions
These were repeated 5 times.
Note that this changes the ABI slightly: XKB_MOD_NAME_CAPS is changed
from "Caps Lock" to "Lock", which is the ordinary legacy mod name for
it. Since its hidden behind a #define, it's best to stay compatible with
the old names (as I think was intended, given that "Mod1", etc. are the
same).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
80ab9f12
|
2012-08-02T23:40:31
|
|
keymap-dump: use ActionTypeText
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
d53fcf53
|
2012-08-02T21:36:30
|
|
keymap-dump: use SITextMatch
text.c has the exact same function.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
20bef734
|
2012-08-02T20:55:12
|
|
keymap-dump: clean up write_buf function
It would have been nice to use open_memstream here if it was portable
enough (maybe someday it will?).
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>
|
|
|
58f8d2c1
|
2012-07-20T17:09:49
|
|
utils: remove Xfuncproto.h and use our own macros
Add XKB_EXPORT to replace _X_EXPORT, and copy the definitions of
_X_ATTRIBUTE_FOO as ATTR_FOO.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
50b25a12
|
2012-07-17T11:03:43
|
|
Use xkb_group_index_t for group variables throughout
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
d0097f4e
|
2012-07-15T15:55:34
|
|
Pass around xkb_key's instead of keycodes
This way we don't need to look up the key every time. We now only deal
with keycodes in the public API and in keycodes.c.
Also adds an xkb_foreach_key macro, which is used a lot.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
ad8875c5
|
2012-07-15T14:02:36
|
|
Remove GroupsWidth macro
Use key->width directly instead.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
4ccb0ef5
|
2012-07-15T13:51:34
|
|
Get rid of group_info
This is 8 bits which hold how many groups the key has, what to do the
key group is out of bound and the group to redirect to if want to. This
may save a few bytes, but is really annoying. So instead, just lay out
the fields separately. We can optimize later in a sane way, with pahole,
bitfields, etc. if we want.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
7d9f0313
|
2012-07-15T13:00:04
|
|
Get rid of struct xkb_key_name
Just embed it directly.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
e8a6a5f0
|
2012-07-15T10:38:05
|
|
Add common xkb_key struct
Instead of having a million arrays from the keycode to various
key-specific info in the keymap, add a single struct xkb_key to hold all
of the data for the key in one object. This way we can pass it around,
do some refactoring and make the code simpler. It's also nice to see
everything in one place.
The keys array is still indexed by keycode, which is suboptimal because
there may be a lot of holes (i.e. unused keycodes between min_key_code
and max_key_code). By the end of this series it would be abstracted
enough to replace it by a hash table or similar if there's ever a need.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
81d029f5
|
2012-07-15T11:52:54
|
|
Replace xkb_keycode_t 'key' variable name by 'kc'
We want to reserve the name 'key' for something else.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
caca60f3
|
2012-07-15T01:45:34
|
|
Move per_key_repeats and enabled_ctrls to keymap
All of the per-key data and global flags are now visible directly in the
keymap.
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>
|
|
|
50fef8eb
|
2012-07-15T00:46:31
|
|
Get rid of xkb_indicator
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
ed082617
|
2012-07-15T00:39:15
|
|
Get rid of xkb_compat_map
Same as xkb_{client,server}_map which were already removed.
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>
|
|
|
219243fe
|
2012-07-15T00:06:11
|
|
Get rid of xkb_client_map
We don't make this distinction anymore, and the separate allocations
just make it harder to reason about. Since we require that all of
symbols, types, compat etc. be present, we should just put stuff
directly in the keymap struct.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
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>
|
|
|
0765064b
|
2012-07-13T18:34:11
|
|
Remove MERGE_ALT_FORM merge mode
The mode comes from the "alternate" keyword, which is unused in
xkeyboard-config and mostly undocumented. Its purpose is to allow to
assign the same key name to multiple key codes, which is not allowed
otherwise (and doesn't make much sense). The xkblib specification
implies that this was part of the overlay functionality, which we also
no longer support.
If we do encounter this keyword, we just treat it as MERGE_DEFAULT. The
keycodes.c code will detect a collision and will ignore all but the
first key code (and the error count is not incremented).
Some peripheral code is also removed as a result.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
f0599675
|
2012-07-11T16:16:20
|
|
dump: add back kccgst names
Readd the component names to the keymap->names struct. This is used when
printing the component, e.g.
xkb_keymap {
xkb_keycodes "evdev+aliases(qwerty)" {
instead of
xkb_keymap {
xkb_keycodes {
This makes diffing against xkbcomp $DISPLAY a bit easier and is kind of
useful anyway.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
fe5bfdf9
|
2012-07-11T16:35:43
|
|
dump: a few more tweaks to match xkbcomp output
Only uppercase / lowercase stuff.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
fedcf370
|
2012-07-12T17:54:09
|
|
dump: use KeyNameText instead of copying
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
1f492901
|
2012-07-11T18:00:31
|
|
Enlarge keysym name buffers and mention in comment
The longest keysym is 27 chars long.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
bc50cdd4
|
2012-06-05T18:46:24
|
|
darray: some changes for convenience
- Make darray_free also initialize the array back to an empty state, and
stop worrying about it everywhere.
- Add darray_mem, to access the underlying memory, which we do manually
now using &darray_item(arr, 0). This makes a bit more clear when we
actually mean to take the address of a specific item.
- Add darray_copy, to make a deep copy of a darray.
- Add darray_same, to test whether two darrays have the same underlying
memory (e.g. if the struct itself was value copied). This should used
where previously two arrays were compared for pointer equality.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
d0718e98
|
2012-06-05T17:48:08
|
|
test/dump: allow to run manually
Without the srcdir envvar (and a couple trivial changes).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
e6ca6fc5
|
2012-06-04T14:04:04
|
|
Fix action= NoAction() printing
Print it explicitly, rather than type=0x00, with all the private data
too.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
f531d1e1
|
2012-06-02T15:25:36
|
|
keymap-dump: Print NoAction actions too
The failure mode here is a little irritating:
- server loads map with ISO_Lock action
- server dumps keymap to string, including:
interpret ISO_Lock+AnyOfOrAll(None) {
action= NoAction();
};
as we don't (yet) print ISO_Lock actions
- client parses keymap from string
- client dumps keymap to string, including:
interpret ISO_Lock+AnyOfOrAll(None) {
};
- this results in a syntax error
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
ebd397e1
|
2012-05-25T17:05:39
|
|
Add xkb_map_get_as_string
Returns a newly-allocated string representing the specified keymap.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|