test


Log

Author Commit Date CI Message
Ran Benita fa1b4543 2016-03-13T20:56:58 test: add a test that all symbol version file is updated It is easy to forget to update these files when adding new symbols. Stolen with slight changes from libinput (commit by Marek Chalupa): https://cgit.freedesktop.org/wayland/libinput/commit/?id=a9f216ab47ea2f643f20ed741b741a2b5766eba3 Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 37ee8e65 2016-03-13T22:56:48 test/x11comp: fix memory leak Signed-off-by: Ran Benita <ran234@gmail.com>
Mike Blumenkrantz 0ce17ef3 2016-01-20T11:40:43 keymap: add xkb_keymap_key_by_name(), xkb_keymap_key_get_name(), tests xkb_keymap_key_by_name() allows finding a keycode from a given keyname and is useful for generating keyboard events to use in regression tests during CI xkb_keymap_key_get_name() is the inverse of xkb_keymap_key_by_name() Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com> [ran: some stylistic tweaks + another test case] Signed-off-by: Ran Benita <ran234@gmail.com>
Kazunobu Kuriyama 91a19905 2015-08-24T13:44:20 test/x11comp: Fix contention between X11 and Xvfb on Mac OS X - Abandon use of -displayfd. - Have x11comp itself look for an unused X11 display number instead.
Ran Benita 74f85d05 2015-08-23T23:02:10 test/x11comp: remove duplicate FOUR_LEVEL_KEYPAD from test keymap The `test/data/keymaps/host.xkb` file contains a duplicate definition of this type. On my computer (linux, xkbcomp 1.3.0, xserver 1.17.2), the test passes as is, but if I remove the duplicate definition, the roundtrip brings it back and the test fails. I can also reproduce it without relation to the test, by loading `test/data/keymaps/host.xkb` (without the duplicate) using xkbcomp -I $(pwd)/test/data/keymaps/host.xkb $DISPLAY and downloading it again using xkbcomp $DISPLAY out.xkb the duplicate is added. On Mac OS X however, the duplicate is removed (correctly), so the test fails there. xkbcommon itself, which was forked from xkbcomp, doesn't have this bug; in fact, doing ./test/print-compiled-keymap -k keymaps/host.xkb removes the duplicate if it is present. This is (probably) a regression in xkbcomp or xserver compared to the versions used in Mac OS X. Since getting a patch for any of these two is hopeless from my experience, I did not try to investigate further. I am not sure why, but if I also add a `PC_SUPER_LEVEL2` type, the duplicate of `FOUR_LEVEL_KEYPAD` doesn't show up. Hopefully the test will work on all platforms now. https://github.com/xkbcommon/libxkbcommon/issues/26 Reported-by: @nuko8 Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita bdf68803 2015-08-23T22:22:11 test/x11comp: small simplifications xkbcomp doesn't need the search-path argument, since we pass an absolute path. Keep the plain -I which clears the search path just to be sure. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 8e1fed6c 2015-03-24T16:40:29 compose: correctly parse modifier syntax As described in: http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=ddf3b09bb262d01b56fbaade421ac85b0e60a69f Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 74482de6 2015-02-03T20:50:52 test/common: print keycode in decimal not hex Keycodes are usually written in decimal, so hex is hard to compare. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a0d2b029 2014-10-17T01:14:57 test/keyseq: test 'map[None] = Level2;' scenario See previous commit for an explanation. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 312182ce 2014-10-16T17:55:46 test/data: add files for model=applealu_ansi layout=us Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita c6ee6371 2014-10-16T17:48:00 test/data: sync to xkeyboard-config 2.13 (Run ./test/data/sync.sh). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita c42b8646 2014-10-14T11:47:25 test/compose: test include statement Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 3f489730 2014-10-14T10:53:38 test/compose: test modifier syntax Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 5cefa5c5 2014-01-29T13:46:42 test/interactive-evdev: add compose support To try, do e.g.: sudo ./test/interactive-evdev -l us -v intl -o compose:ralt -d Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 10a7a2bd 2013-10-27T20:37:27 test/compose: add new test Some results from the benchmark (compilation of en_US.UTF-8/Compose): $ grep 'model name' /proc/cpuinfo model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz $ uname -a Linux ran 3.16.1-1-ARCH #1 SMP PREEMPT Thu Aug 14 07:40:19 CEST 2014 x86_64 GNU/Linux $ ./test/compose bench compiled 1000 compose tables in 7.776488331s So according to the above benchmark and valgrind --tool=massif, an xkb_compose_table adds an overhead of about ~8ms time and ~130KB resident memory. For contrast, a plain US keymap adds an overhead of ~3ms time and 90KB resident memory. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita bc3b4c08 2014-10-02T22:03:28 Move benchmarks from tests to their own files in bench/ The tests only contain tests, and the benchmarks are more visible. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 68962aa1 2014-09-21T23:54:34 keymap-dump: combine modifier_map's with the same modifier A bit less efficient, but makes for shorter, nicer output. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 24846080 2014-09-11T14:08:12 test/keyseq: add test Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a931740c 2014-09-10T13:29:52 keycodes: fix keymap compilation with no aliases and malloc(0)==NULL If the keymap doesn't have any key-aliases (which is certainly possible), the calloc(num_key_aliases, ...) is allowed to return NULL according to the C standard, but this is not an error. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita ba985629 2014-09-06T11:29:15 test: make most tests portable by copying linux/input.h locally There is really no reason to deny these tests from different platforms only for a few #defines. The only linux-only test (or test program, it is not run by make check) is interactive-evdev, which actually uses evdev. Signed-off-by: Ran Benita <ran234@gmail.com>
Pino Toscano e95fb475 2014-09-06T11:05:44 Remove <linux/input.h> include from test/x11comp.c libxkbcommon 0.4.3 introduces a new test, x11comp, which does not build on non-Linux OSes because of the unconditional <linux/input.h> include. This seems not needed even on Linux, so attached there is a simple patch to remove it. https://bugs.freedesktop.org/show_bug.cgi?id=83551 Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita fc95057c 2014-09-01T17:20:40 test/x11comp: don't hang if Xvfb is not available If Xvfb is not present, posix_spawn still forks, but the child fails. In that case, since we left the write fd of the pipe open in the parent, we just kept waiting on the read() without noticing that the other side is dead. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita f3597f1b 2014-08-18T21:03:06 test/state: add test_update_mask() test Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a95c4e83 2014-08-18T19:47:10 test/x11comp: server writes \n to displayfd Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 4df720b4 2014-08-09T22:14:34 test/x11-keyseq: new test It is like test/stringcomp, only instead of using xkb_keymap_new_from_string(), it uses xkbcomp to upload the keymap to a dummy Xvfb X server and then xkb_x11_keymap_new_from_device(). If any of these components are not present or fails, the test is shown as skipped. The test is messy, fragile, limited and depends on external tools, but I will improve on that later -- it's better to have a test. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 5058620c 2014-07-27T16:36:11 interactive-evdev: don't use sysexits.h Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 40f109af 2014-07-27T14:24:20 ast-build: make sure InterpDef is freeable With the following two rules: InterpretDecl : INTERPRET InterpretMatch OBRACE VarDeclList CBRACE SEMI { $2->def = $4; $$ = $2; } ; InterpretMatch : KeySym PLUS Expr { $$ = InterpCreate($1, $3); } | KeySym { $$ = InterpCreate($1, NULL); } ; And the fact that InterpCreate doesn't initialize ->def, if the VarDeclList fails, the %destructor tries to recursively free the uninitialized ->def VarDef. So always initialize it. That was the only problematic code in the parser for %destructor (I'm pretty sure). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita f5182bbd 2014-07-26T22:29:22 test: add file with a syntax error We didn't really have any. It also a exposes a memory leak, since the parser doesn't clean up the AST nodes of the discarded symbols. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 67d884ec 2014-06-01T15:24:10 Remove unnecessary !!(expressions) _Bool already does that. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 54174409 2014-03-27T17:42:20 state: fix consumed modifier calculation The current calculation is in short: entry ? (entry->mask & ~entry->preserve) : 0 This changes it be type->mask & ~(entry ? entry->preserve : 0) This is what Xlib does. While less intuitive, it is actually more correct, if you follow this deduction: - The key group's type->mask defines which modifiers the key even cares about. The others are completely irrelevant (and in fact they are masked out from all sided in the level calculation). Example: NumLock for an alphabetic key. - The type->mask, the mods which are not masked out, are *all* relevant (and in fact in the level calculation they must match *exactly* to the state). These mods affect which level is chosen for the key, whether they are active or not. - Because the type->mask mods are all relevant, they must be considered as consumed by the calculation *even if they are not active*. Therefore we use type->mask instead of entry->mask. The second change is what happens when no entry is found: return 0 or just take preserve to be 0? Let's consider an example, the basic type type "ALPHABETIC" { modifiers = Shift+Lock; map[Shift] = Level2; map[Lock] = Level2; level_name[Level1] = "Base"; level_name[Level2] = "Caps"; }; Suppose Shift+Lock is active - it doesn't match any entry, thus it gets to level 0. The first interpretation would take them both to be unconsumed, the second (new one) would take them both to be consumed. This seems much better: Caps is active, and Shift disables it, they both do something. This change also fixes a pretty lousy bug (since 0.3.2), where Shift appears to apparently *not* disable Caps. What actually happens is that Caps is not consumed (see above) but active, thus the implicit capitalization in get_one_sym() kicks in and capitalizes it anyway. Reported-by: Davinder Pal Singh Bhamra Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 3cfa7fda 2014-03-21T23:00:37 state: apply control transformation on utf8/utf32 keysym strings This is required by the specification: http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Control_Modifier and clients expect this to happen. https://bugs.freedesktop.org/show_bug.cgi?id=75892 Reported-by: Gatis Paeglis <gatis.paeglis@digia.com> Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita b973d71e 2014-03-21T23:00:17 state: add xkb_state_key_get_{utf8,utf32}() API functions These functions generally have the same effect as xkb_state_key_get_syms() + xkb_keysym_to_utf{8,32}(). So why add them? - They provide a slightly nicer interface, especially if the string is the only interest. - It makes the handling of multiple-keysyms-to-utf8 transparent. For the designated use-case of multiple-keysyms (unicode combining characters), this is a must. We also validate the UTF-8, which the user might not otherwise do. - We will need to apply some transformation on the resulting string which depend on the xkb_state. This is not possible with the xkb_keysym_* functions. With these functions, the existing xkb_keysym_to_utf{8,32}() are not expected to be used by a typical user; they are "raw" functions. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 2bbaf7c7 2014-02-09T13:50:21 Add utf8.{c,h} for common UTF-8 util functions We need to validate some UTF-8, so this adds an is_valid_utf8() function, which is probably pretty slow but should work correctly. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 6adf17bd 2014-02-28T15:12:16 interactive-x11: beef up select_events a bit - Specify in detail which parts of the events we care about. In theory the X server should not bother us with things we didn't ask for. In practice it still does, but oh well. - Use the _aux version of select_events. This is the correct one to use, the non-aux version is useless. Signed-off-by: Ran Benita <ran234@gmail.com>
Jasper St. Pierre 4fb7b06b 2014-02-21T18:09:00 state: Add xkb_state_key_get_consumed_mods This retrieves the mask of consumed modifiers for a given key and state, which is helpful for toolkits without having them to do it one modifier at a time, or pass in 0xFFFFFFFF to xkb_state_remove_consumed_mods to "reverse-engineer" the consumed mods.
Ran Benita 11a9f76b 2014-02-15T23:27:23 keymap-dump: don't print "affect=lock" in PtrLock It's the same as no flags, so might as well not print it. (In fact it is slightly harmful, because it actively *clears* the affect flags, which might have been set in some other manner. But in practice this cannot happen). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 067c8c25 2014-02-10T13:13:26 test/rmlvo-to-kccgst: use default RMLVO values in translation The tool's supposed to display exactly the same results as the library code. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 973b8fd4 2014-02-08T16:40:20 api: deprecate XKB_MAP_COMPILE_PLACEHOLDER, and use KEYMAP instead of MAP The PLACEHOLDER was not meant to be used, but c++ doesn't like passing 0 to enums, so it was used. For this reason we add all the NO_FLAGS items, so the PLACEHOLDER shouldn't be used anymore. Second, XKB_MAP is the prefix we used ages ago, KEYMAP is the expected prefix here. So deprecate that as well. The old names may still be used through the xkbcommon-compat.h header, which is included by default (no need to include directly). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 94e0be0d 2014-02-08T00:42:54 test/state: fix tautological test test/state.c:376:5: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 623b10f8 2014-02-08T00:27:54 Fix sign-compare warnings Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 623602cb 2014-02-07T01:35:56 test: don't print control characters in interactive tests Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 2f93c788 2013-07-30T15:06:40 x11: add a couple of tests Add two tests: ./test/interactive-x11 which is like test/interactive-evdev, but should behave exactly like your X keyboard and react to state and keymap changes - in other words, just like typing in xterm. Press ESC to exit. ./test/x11 which currently should only print out the same keymap as xkbcomp $DISPLAY out.xkb (modulo some whitespace and some constructs we do not support.) Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita d63e0ab8 2013-07-30T13:38:51 test: rename test/interactive to interactive-evdev And share the key-printing functions. In preparation for adding more interactive-* variants. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 4841ea0c 2014-01-11T16:56:20 test/state: fix some *_{is,are}_active() tests These functions also return -1 on invalid input. The original tests didn't check that, but used !tests instead. Since then we've changed them, but some were missed, and for some we forgot to remove the ! (or you can say they were extra clever). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 31430670 2014-01-11T16:40:42 Fix some cppcheck warnings Someone was nice enough to run this for us: ftp://ftp.sunet.se/pub/Linux/distributions/Debian/debian/pool/main/libx/libxkbcommon/libxkbcommon_0.3.1.orig.tar.gz [libxkbcommon-0.3.1/src/keymap.c:86]: (style) The scope of the variable 'j' can be reduced. [libxkbcommon-0.3.1/src/keymap.c:87]: (style) The scope of the variable 'key' can be reduced. [libxkbcommon-0.3.1/src/keysym-utf.c:843]: (style) The scope of the variable 'mid' can be reduced. [libxkbcommon-0.3.1/src/state.c:992]: (style) The scope of the variable 'str' can be reduced. [libxkbcommon-0.3.1/src/xkbcomp/action.c:467]: (style) The scope of the variable 'absolute' can be reduced. [libxkbcommon-0.3.1/src/xkbcomp/rules.c:468]: (style) The scope of the variable 'consumed' can be reduced. [libxkbcommon-0.3.1/src/xkbcomp/rules.c:862]: (style) The scope of the variable 'mlvo' can be reduced. [libxkbcommon-0.3.1/src/xkbcomp/rules.c:863]: (style) The scope of the variable 'kccgst' can be reduced. [libxkbcommon-0.3.1/src/xkbcomp/rules.c:865]: (style) The scope of the variable 'match_type' can be reduced. [libxkbcommon-0.3.1/src/xkbcomp/symbols.c:753]: (style) The scope of the variable 'toAct' can be reduced. [libxkbcommon-0.3.1/src/xkbcomp/symbols.c:1573]: (style) The scope of the variable 'key' can be reduced. [libxkbcommon-0.3.1/test/common.c:80]: (warning) %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [libxkbcommon-0.3.1/test/interactive.c:358]: (style) The scope of the variable 'nevs' can be reduced. [libxkbcommon-0.3.1/test/interactive.c:236]: (style) Checking if unsigned variable 'nsyms' is less than zero. [libxkbcommon-0.3.1/test/interactive.c:226]: (style) Unused variable: unicode Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita b246edc6 2013-12-02T14:16:45 test/atom: add test for atom table Mostly a random test. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita ba7530fa 2013-11-27T13:43:57 scanner: restore lost DIVIDE token I don't know how this could have happened. Luckily this token is completely useless. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 65f9980b 2013-10-14T19:05:24 rules: fix scanning of line-continuation without leading space We were failing to scan something like\ this correctly. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita f813bdbf 2013-10-09T12:23:46 rulescomp: increase BENCHMARK_ITERATIONS from 1000 to 2500 1000 is a bit too low for statistical significance on this 6 years old CPU. Since the benchmark is run manually this shouldn't be a problem. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 59fb79e7 2013-09-25T10:05:26 test/state: fix missing xkb_state_unref Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 2a2a8d7d 2013-08-13T18:57:43 state: apply capitalization transformation on keysyms The xkbproto spec says: http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Lock_Modifier If the Lock modifier is not consumed by the symbol lookup process, routines that determine the symbol and string that correspond to an event should capitalize the result. This was not an issue until now, because most xkeyboard-config keymaps do not utilize this "feature", and specify the keysyms for the Lock modifier explicitly instead. However, some keymaps do depend on it, e.g. ch(fr) for eacute and others. The spec goes on to describe two options for doing this transformation: locale-sensitive and locale-insensitive. We opt for the latter; it is less desirable but we don't want *that* headache. Also, only xkb_state_key_get_one_sym() is changed; xkb_state_key_get_syms() is left as-is, and always reports the untransformed keysyms. This is for the following reasons: - The API doesn't allow it, since we return a const pointer directly to the keymap keysyms table and we can't transform that. - The transformation doesn't make sense for multiple-keysyms. - It can be useful for an application to get the "raw" keysyms if it wants to (e.g. maybe it wants to do the transformation itself). Finally, note that xkb_state_mod_index_is_consumed() does *not* report Lock as consumed even if it was used in the transformation. This is what Xlib does. This definitely doesn't fall under the "hard to misuse" API rule but it's the best we can do. https://bugs.freedesktop.org/show_bug.cgi?id=67167 Reported-By: Gatis Paeglis <gatis.paeglis@digia.com> Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 9e92319d 2013-08-13T18:55:09 test/interactive: use xkb_state_key_get_one_sym() when there's only 1 Kind of odd, but get_one_sym() will be getting a different behavior. Real life users *should* pick one or the other. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 1499eedd 2013-08-13T18:52:46 keysym: add xkb_keysym_to_{lower,upper} These functions are needed later; they are not API functions. The capitalization is not locale sensitive. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 9cef902d 2013-08-14T11:35:01 test: make sure keycode 0 works fine It is a legal keycode but we never tried it actually. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 7caa1af2 2013-08-13T14:45:33 scanner: don't fail over unknown escape sequence This is too strict, and causes symbols/cz to fail parsing. Instead, just emit a warning (not shown by default): xkbcommon: WARNING: cz:75:19: unknown escape sequence in string literal https://bugs.freedesktop.org/show_bug.cgi?id=68056 Reported-By: Gatis Paeglis <gatis.paeglis@digia.com> Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita e91d2653 2013-08-01T23:09:46 scanner: allow empty key name literals Some keymaps actually have this, like the quartz.xkb which is tested. We need to support these. https://bugs.freedesktop.org/show_bug.cgi?id=67654 Reported-By: Gatis Paeglis <gatis.paeglis@digia.com> Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita e731b251 2013-08-01T20:24:27 xkbcomp: handle empty keymaps We should handle empty xkb_keycode and xkb_symbol sections, since xkbcomp handles them, and apparently XQuartz uses it. There are also files for it in xkeyboard-config (rules=base model=empty layout=empty, which translate to keycodes/empty and symbols/empty). https://bugs.freedesktop.org/show_bug.cgi?id=67654 Reported-By: Gatis Paeglis <gatis.paeglis@digia.com> Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 7f1b7a1c 2013-07-25T13:21:33 test/keyseq: add de(neo) Level{6,7,8} tests Signed-off-by: Ran Benita <ran234@gmail.com>
Pino Toscano ec9a02a2 2013-07-24T10:05:02 Get rid of the usage of PATH_MAX PATH_MAX is optional in POSIX, so avoid its unconditional usage allocating and freeing buffers as needed. To avoid too many malloc/free in the for loop in FindFileInXkbPath, a buffer is grown according to the size needed at each iteration.
Ran Benita 0c8e9e0c 2013-07-22T18:43:53 test: sync test/data from xkeyboard-config 2.9 Needed for some tests. The tests need some adjustment, mostly because of the resolution of xkeyboard-config bug https://bugs.freedesktop.org/show_bug.cgi?id=50935 Also add the 'ch' symbols file for future tests. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita c00ea5ff 2013-07-22T10:51:22 atom: really work with non-NUL-terminated strings Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 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>
Matthias Clasen b06de307 2013-05-09T15:31:21 Add keycode min/max and iteration API Add three new pieces of API: - xkb_keymap_min_keycode does what it says on the tin - xkb_keymap_max_keycode likewise - xkb_keymap_key_for_each calls the provided function once for every valid key in the keymap Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 17a956d8 2013-05-09T14:47:09 Widen keycode range to 8/255 if possible (bug #63390) If the keycode range is smaller than 8 → 255, artifically widen it when dumping the keymap as not to displease X. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
David Herrmann 36f55c49 2013-03-11T12:53:39 keymap: add xkb_keymap_new_from_buffer() The current API doesn't allow the caller to create keymaps from mmap()'ed files. The problem is, xkb_keymap_new_from_string() requires a terminating 0 byte. However, there is no way to guarantee that when using mmap() so a user currently has to copy the whole file just to get the terminating zero byte (assuming they cannot use xkb_keymap_new_from_file()). This adds a new entry xkb_keymap_new_from_buffer() which takes a memory location and the buffer size in bytes. Internally, we depend on yy_scan_{string,byte}() helpers. According to flex documentation these already copy the input string because they are wrappers around yy_scan_buffer(). yy_scan_buffer() on the other hand has some insane requirements. The buffer must be writeable and the last two bytes must be ASCII-NUL. But the buffer may contain other 0 bytes just fine. Because we don't want these constraints in our public API, xkb_keymap_new_from_buffer() needs to create a copy of the input memory. But it then calls yy_scan_buffer() directly. Hence, we have the same number of buffer-copies as with *_from_string() but without the terminating 0 requirement. The explicit yy_scan_buffer() call is preferred over yy_scan_byte() so the buffer-copy operation is not hidden somewhere in flex. Maybe some day we no longer depend on flex and can have a zero-copy API. A user could mmap() a file and it would get parsed right from this buffer. But until then, we shouldn't expose this limitation in the API but instead provide an API that some day can work with zero-copy. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> [ran: rebased on top of my branch] Conflicts: Makefile.am src/xkbcomp/xkbcomp.c
Daniel Stone 38654f5e 2013-03-27T22:40:58 Add key-sequence checking to rulescomp Make sure we're actually getting the keymaps we're hoping to compile. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 4d7600bd 2013-03-19T10:59:38 test: Add va_list variant of test_key_seq For use when chaining tests. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 40c46ecd 2013-03-01T23:47:59 Allow NULL rmlvo for xkb_keymap_new_from_names Previously we allowed you to pass a names struct with five NULL members, but not just pass NULL for the struct itself. This was pretty dumb. :( Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 22ba1fa1 2013-03-18T22:15:20 test: Add environment checking to rulescomp To ensure that overriding RMLVO from the environment works. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 964b2a40 2013-03-19T10:29:49 test: Suppress RMLVO environment inheritance by default But add a flag to allow it for later usage. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone fbe5e675 2013-02-28T10:48:40 Add environment overrides for default RMLVO You can now set default values in the environment, as well as a context option to ignore the environment, e.g. for tests. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone d4c22ecc 2013-03-18T21:03:00 test: Use test_get_context() in log.c Since the only behavioural change is overriding default includes. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 54f95f49 2013-03-18T21:02:35 test: Add flags argument to test_get_context() Allowing overriding of environment suppression, at first. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone a1f203c0 2013-03-18T20:55:18 test: Move test_key_seq to common.c Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita 559252a1 2013-03-08T16:31:33 keyseq: add a couple of tests Tests the filter refcounting. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 79329e10 2013-03-02T19:01:18 Don't try to build linux-specific tests on non-linux Some tests use linux/input.h (and epoll), but we're building on some other kernels (e.g. debian freebsd). We could just copy the file but it's GPL. We could also skip the tests (exit code 77) but it doesn't really matter. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 14842d6d 2013-03-01T21:48:02 keymap: abstract a bit over the keymap format Make it a bit easier to experiment with other formats. Add a struct xkb_keymap_format_operations, which currently contains the keymap compilation and _get_as_string functions. Each format can implement whatever it wants from these. The current public entry points become wrappers which do some error reporting, allocation etc., and calling to the specific format. The wrappers are all moved to src/keymap.c, so there are no XKB_EXPORT's under src/xkbcomp/ anymore. The only format available now is normal text_v1. This is all not very KISS, and adds some indirection, but it is helpful and somewhat cleaner. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a0fc9066 2013-02-28T21:06:35 test/rmlvo-to-kccgst: free memory before exit Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 4a59c84e 2013-02-25T12:09:17 keymap-dump: remove some ugly empty lines xkbcomp prints them too, but that's just annoying. Also xkb_keycodes doesn't have it already. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita e95dac76 2013-02-25T12:03:06 keymap-dump: don't indent after xkb_keymap { xkbcomp doesn't indent there, so it's easier to diff. Also saves some horizontal space which is sorely needed when looking at these files (especially the xkb_symbols). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita c7aef166 2013-02-19T15:57:14 keysym: print unicode keysyms uppercase and 0-padded Use the same format as XKeysymToString. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 10c351f5 2013-02-17T22:50:12 test/interactive: change variable name for 'xkb' to 'keymap' Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 089c3a18 2013-02-17T14:59:50 state: fix unbound virtual modifier bug Recent xkeyboard-config introduced the following line in symbols/level3: vmods = LevelThree, However, the XKM format which xkbcomp produces for the X server can't handle explicit virtual modifiers such as this: https://bugs.freedesktop.org/show_bug.cgi?id=4927 So by doing the following, for example: setxkbmap -layout de (or another 3-level layouts) xkbcomp $DISPLAY out.xkb xkbcomp out.xkb $DISPLAY The modifier is lost and can't be used for switching to Level3 (see the included test). We, however, are affected worse by this bug when we load the out.xkb keymap. First, the FOUR_LEVEL_ALPHABETIC key type has these entries: map[None] = Level1; map[Shift] = Level2; map[Lock] = Level2; map[LevelThree] = Level3; [...] Now, because the LevelThree virtual modifier is not bound to anything, the effective mask of the "map[LevelThree]" entry is just 0. So when the modifier state is empty (initial state), this entry is chosen, and we get Level3, instead of failing to match any entry and getting the default Level1. The difference in behavior from the xserver stems from this commit: acdad6058d52dc8a3e724dc95448300850d474f2 Which removed the entry->active field. Without bugs, this would be correct; however, it seems in this case we should just follow the server's behavior. The server sets the entry->active field like so in XKBMisc.c: /* entry is active if vmods are bound */ entry->active = (mask != 0); The xkblib spec explains this field, but does not specify how to initialize it. This commit does the same as above but more directly. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 0ad8bf57 2013-02-17T14:32:36 test/interactive: also print the level Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita bc7b2ff2 2013-02-17T13:39:41 test/keyseq: re-add de(neo) level5 test See: https://bugs.freedesktop.org/show_bug.cgi?id=50935 This works now after syncing with recent xkeyboard-config. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 40581106 2013-02-17T11:22:41 Sync test data from xkeyboard-config Sync the files again from xkeyboard-config 2.8, since there have been some changes we should test against. Also added a script test/data/sync.sh if we want to do it again in the future. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita d87035ad 2012-11-07T18:58:18 test/keysym: '\e' is non-standard test/keysym.c:139:43: warning: non-ISO-standard escape sequence, '\e' Didn't warn about it before.. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 7891c917 2012-11-05T21:34:59 keysym-utf: also translate special keysyms like Tab and Return The keysym2ucs.c file apparently leaves out some keysyms, which libX11 deals with separately (like in _XkbHandleSpecialSym()). The problematic keysyms are the keypad ones (for which we already added some support) and keysyms which use 0xff** instead of 0x00** < 0x20. This code should fix them properly, as much as I could gather from libX11 and http://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c and other sources (which are not aware of locale). https://bugs.freedesktop.org/show_bug.cgi?id=56780 Reported-by: Gatis Paeglis <gatis.paeglis@digia.com> Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 94155878 2012-10-29T20:20:51 test/keyseq: add test for setting depressed group Tests the SetGroup action is working properly. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 7261f404 2012-10-29T01:00:27 state, context: allow passing NULL to *_unref() For error handling code, it's nice to be able to pass NULL to these function without worrying about segfaults ensuing. free() sets the precedent here. Also document this fact. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita c1c1b720 2012-10-24T23:27:40 test: add key processing benchmark This runs a bunch of random keys against xkb_state_update_key() and xkb_state_key_get_one_sym(), in a fairly unintelligent way. It might be nice to check when modifying this code path, or changing it, to see things haven't slowed down considerably. However, given the numbers this benchmark gives, it is pretty clear that we are not going to be the bottleneck for anything. So this can more-or-less be ignored. Incidentally, this also turned out to be a poor man's fuzzer, because it turned up the fix in the previous commit. Maybe we should consider beefing it up with an actual 'break stuff' intention and running it as part of 'make check'. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita e24ed49c 2012-10-23T10:05:16 test/interactive: use num_layouts_for_key() This is the more appropriate for a specific key (also considering the num_layouts() is a bit of a made-up value). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a807494e 2012-10-22T21:16:35 test/interactive: add option to show state changes Pass -c to see. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 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>
David Herrmann 7b3bd11f 2012-10-16T16:05:34 Add xkb_keysym_from_name() flags argument for case-insensitive search This adds a flags argument to xkb_keysym_from_name() so we can perform a case-insensitive search. This should really be supported as many keysyms have really weird capitalization-rules. However, as this may produce conflicts, users must be warned to only use this for fallback paths or error-recovery. This is also the reason why the internal XKB parsers still use the case-sensitive search. This also adds some test-cases so the expected results are really produced. The binary-size does _not_ change with this patch. However, case-sensitive search may be slightly slower with this patch. But this is barely measurable. [ran: use bool instead of int for icase, add a recommendation to the doc, and test a couple "thorny" cases.] Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Ran Benita 523e46f4 2012-10-12T10:15:43 Change log env vars to XKB_LOG_LEVEL/VERBOSITY A bit more consistent and descriptive. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita bbf388ec 2012-10-11T16:54:17 Make xkb_keymap_num_leds return the index range instead of active count Currently xkb_keymap_num_leds() returns a count of valid (settable) leds. Because the indexes might be non-consecutive, and some leds might not be settable, it is incorrect to use this function for iterating over the leds in the keymap. But this is the main use case of this function, so instead of the current behavior we adapt the function to the use case by making it return the needed range of iteration. The caller needs to handle invalid intermittent indexes, though. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a05fbc17 2012-10-10T19:14:35 stringcomp: test compilation of a dump of a keymap created from rules This would have caught the regression fixed in 2ac319c. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 2f4db8a9 2012-10-10T09:47:31 keymap, state: don't assume led index < xkb_keymap_num_leds xkb_keymap_num_leds() returns the number of leds that have any possibility of being set. Even if a led is defined but can not be set in any way, it is not counted. In a few places currently we assume that led indexes are smaller than this number, which is wrong both for the above reason and for the fact that the xkb format actually allows explicitly setting the indicator index, which means that the indexes might be non-consecutive. We don't really have good API to iterate on leds, now, because xkb_keymap_num_leds is pretty useless. To work around that we use sizeof(xkb_led_mask_t) * 8. This makes the "Group 2" led work (try switching to a layout other than the first in test/interactive). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 9179fed7 2012-10-09T20:48:35 keysym: fix xkb_keysym_is_upper/lower() to work properly Our current code (taken from the xserver) doesn't handle unicode keysyms at all, and there seem to be some other changes compared to libX11, which is what xkbcomp uses. So we just copy the code that does that from libX11. It would be much better to not have to hardcode unicode tables like that, but it's probably better than dealing with glibc locale stuff for now. It also doesn't affect our binary size much. Signed-off-by: Ran Benita <ran234@gmail.com>