|
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>
|
|
|
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>
|
|
|
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>
|
|
93f6517c
|
2012-08-03T04:07:33
|
|
stringcomp: Make test more punishing
Recreate the old test/dump scenario, where we test the following map:
- rules: evdev
- model: pc104
- layout #1: us
- layout #2: ru
- layout #3: ca(multix)
- layout #4: de(neo)
This is ever so slightly altered from the xkbcomp output; running the
following:
setxkbmap -rules evdev -model pc105 -layout us,ru,ca,de -variant
,,multix,neo -print | xkbcomp -xkb - -
will give you a map with RCTL added to the modifier_map for both Control
and Mod3. Running the output through xkbcomp -xkb - - again, will give
you RCTL only added to Mod3.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
e756e9b5
|
2012-08-03T04:02:31
|
|
test/dump: Remove superfluous test
No longer necessary now we have stringcomp doing a full round-trip test
for us.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
6701fb5f
|
2012-08-03T03:54:44
|
|
stringcomp: Remove unnecessary Level1 mappings
As a map will implicitly go to level one unless explicitly mentioned
otherwise, remove all explicit =Level1 mappings, except for those with
preserve entries.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
39da9274
|
2012-08-03T03:38:46
|
|
stringcomp: Update input file for output changes
Bring the input file into line with recent changes to the dump output,
so we're as close as we can get to a round trip.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
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>
|
|
|
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>
|
|
|
c6279b8b
|
2012-07-23T21:21:03
|
|
expr: don't divide by zero
Calculator parser 101.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
3640e14d
|
2012-07-13T00:39:34
|
|
Add multiple-keysyms-per-level to test data
Make sure this keeps on working.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
a77e9a92
|
2012-07-13T00:12:57
|
|
tests: Update dump.data for recent fixes
Makes the test pass again.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
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>
|
|
|
9e505225
|
2012-07-12T19:28:52
|
|
symbols: fix bug in modifier_map handling
The code used to match a keysym to a keycode (see added comment)
differed in behavior from xkbcomp, always taking the first key it found.
This caused some incorrect interpretation of the xkeyboard-config data,
for example the one corrected in dump.data (see the diff): since the
de-neo layout sets the both_capslock option, the Left Shift key (LFSH)
has the Caps_Lock keysym in group 4 level 2; now since
keycode(Left Shift) = 50 < keycode(Caps Lock) = 64
the Left Shift one was picked, instead of the Caps Lock one which is
group 1 level 1. The correct behavior is to pick according to group,
level, keycode.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
62deaeb5
|
2012-07-12T14:42:31
|
|
Import dataset into test/data/
Use a self-contained dataset instead of relying on a globally-installed
set. Data taken from xkeyboard-config 2.5.1.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
059c1842
|
2012-07-12T12:02:19
|
|
Move test data files to test/data/keymaps
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|