kmx git

Commit	Date	Message
7f04ffc4	2012-08-29T12:10:28	rules: fix check for appending '\|' character when applying There are two ways to separate multiple files in XKB include statements: '+' will cause the later file to override the first in case of conflict, while '\|' will cause it augment it (this is done by xkbcomp). '!' is unrelated here. Since '\|' is practically never used, this wasn't noticed. In the modified test, the '\|some_compat' previously was just ignored. Signed-off-by: Ran Benita <ran234@gmail.com>
2a026f6f	2012-08-28T15:55:35	test/data/symbols: keypad can only have one default section Avoids a warning, from xkeyboard-config: commit 6676053f2c93596c2aaa9905151a5c76355a1540 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Fri Jun 29 09:53:45 2012 +1000 symbols: keypad can only have one default section Warning: Multiple default components in keypad Using x11, ignoring pointerkeys Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> 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>
7ef359de	2012-08-12T18:16:52	rulescomp: remove bad failtests Since we now handle empty model/layout, the last couple of tests should not fail. The reason they do is bacause they try to use a non-existent "base" rules file. When the file is brought in these tests do not fail. Since we already test for non-existent rules file, we can remove them, and refine the other tests a bit. 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>
19f814f9	2012-07-11T14:08:28	rules: fix parsing of multiple options This was broken by commit 18d331b86b4942ba54fe087ca07e47c9383d768b (where only the first option out of a comma-separated string was matched). Do it correctly this time and add a test. 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>
869c6871	2012-05-19T02:35:15	rules: add test Add a non-extensive test to check that some basic things (e.g. rule matching, var substitution, indexes and groups) work as expected. Signed-off-by: Ran Benita <ran234@gmail.com>
4b49e0a1	2012-03-31T02:44:39	Overhaul test suite Rewrite all of the current tests in the following ways: - Instead of the current mix of C and shell, just use single-process pure C file per test. All of the .sh files are removed, but everything that was tested is ported. - Instead of handling the test logs ourselves, use Automake's "parallel-test" mechanism. This will create a single log file for each test with it's stdout+stderr, and a top level "test-suite.log" file for all the failed tests. - The "parallel-tests" directive also makes the test run in parallel, so "make check" runs faster. - Also use the "color-tests" directive to have the "make check" output colorized. Who doesn't like to see PASS in green? - All of the test data files are moved into the test/data subdirectory. That way we can just put the directory in EXTRA_DIST and forget about it. - The test/Makefile.am file is consolidated into the main Makefile.am, for a completely non-recursive build. Right now the tests are completely independent and just use simple assert()'s. More sophistication can be added as needed. It should also be noted that it's still possible to use shell, python, etc. if a test wants more flexibility than C can provide, just do as before. Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Updated for xkb_keymap changes.]

7f04ffc4

2012-08-29T12:10:28

rules: fix check for appending '|' character when applying There are two ways to separate multiple files in XKB include statements: '+' will cause the later file to override the first in case of conflict, while '|' will cause it augment it (this is done by xkbcomp). '!' is unrelated here. Since '|' is practically never used, this wasn't noticed. In the modified test, the '|some_compat' previously was just ignored. Signed-off-by: Ran Benita <ran234@gmail.com>

2a026f6f

2012-08-28T15:55:35

test/data/symbols: keypad can only have one default section Avoids a warning, from xkeyboard-config: commit 6676053f2c93596c2aaa9905151a5c76355a1540 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Fri Jun 29 09:53:45 2012 +1000 symbols: keypad can only have one default section Warning: Multiple default components in keypad Using x11, ignoring pointerkeys Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> 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>

7ef359de

2012-08-12T18:16:52

rulescomp: remove bad failtests Since we now handle empty model/layout, the last couple of tests should not fail. The reason they do is bacause they try to use a non-existent "base" rules file. When the file is brought in these tests do not fail. Since we already test for non-existent rules file, we can remove them, and refine the other tests a bit. 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>

19f814f9

2012-07-11T14:08:28

rules: fix parsing of multiple options This was broken by commit 18d331b86b4942ba54fe087ca07e47c9383d768b (where only the first option out of a comma-separated string was matched). Do it correctly this time and add a test. 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>

869c6871

2012-05-19T02:35:15

rules: add test Add a non-extensive test to check that some basic things (e.g. rule matching, var substitution, indexes and groups) work as expected. Signed-off-by: Ran Benita <ran234@gmail.com>

4b49e0a1

2012-03-31T02:44:39

Overhaul test suite Rewrite all of the current tests in the following ways: - Instead of the current mix of C and shell, just use single-process pure C file per test. All of the .sh files are removed, but everything that was tested is ported. - Instead of handling the test logs ourselves, use Automake's "parallel-test" mechanism. This will create a single log file for each test with it's stdout+stderr, and a top level "test-suite.log" file for all the failed tests. - The "parallel-tests" directive also makes the test run in parallel, so "make check" runs faster. - Also use the "color-tests" directive to have the "make check" output colorized. Who doesn't like to see PASS in green? - All of the test data files are moved into the test/data subdirectory. That way we can just put the directory in EXTRA_DIST and forget about it. - The test/Makefile.am file is consolidated into the main Makefile.am, for a completely non-recursive build. Right now the tests are completely independent and just use simple assert()'s. More sophistication can be added as needed. It should also be noted that it's still possible to use shell, python, etc. if a test wants more flexibility than C can provide, just do as before. Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Updated for xkb_keymap changes.]

kc3-lang/libxkbcommon/test/data

test/data

Log