test/.gitignore


Log

Author Commit Date CI Message
Peter Hutterer d1cb8ad4 2018-08-14T11:16:30 test: add a tool to test-compile all LVO combinations from xkeyboard-config This test contains of two parts: - a simple program to convert RMLVO commandline arguments into a keymap (and print that keymap if requested). - a python script that runs through rules/evdev.xml, and tries to compile a keymap for sort-of every layout/variant/option combination. Sort-of, because we can have multiple options and it really only does one per layout(variant) combination. Same thing can be done using xkbcomp, but right now it doesn't take that as argument, it's hard-coded. This takes quite a while, installing python-tqdm is recommended to see fancy progress bars instead of just miles of dumps. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Daniel Stone 7e123a10 2016-04-12T12:03:32 test: Add interactive-wayland interactive-wayland is very similar to x11/xev, and dumps out as much state as possible. It provides no titlebar and a completely random cursor, but such is life. Signed-off-by: Daniel Stone <daniels@collabora.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>
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 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 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 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 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>
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
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 2c96828f 2012-09-19T16:44:15 test: add print-compiled-keymap tool This just prints the compiled keymap string for to the given command line arguments. This often useful when developing. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 480f919d 2012-08-29T11:54:05 test: add rmlvo-to-kccgst tool For a quick look at what components result from the rules. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 5a51ce8b 2012-08-09T01:55:30 Fix warning Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 4c212753 2012-04-08T02:20:39 Add an interactive evdev test The program reads key events from evdev input devices, puts them through the library and prints some information about them. It's nice for experimenting, quick testing and trying to break it with random stuff (already found some!). It is called "interactive" for lack of a better name. It's a bit hackish, but can easily be extended, made more portable etc, in the future. Signed-off-by: Ran Benita <ran234@gmail.com> Conflicts: Makefile.am test/.gitignore
Ran Benita 3dc1252d 2012-07-22T19:38:14 Add test for logging functionality Just to make sure everything works properly. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 0015604a 2012-04-10T21:20:27 Add a test for the results of key sequences This test verifies the core purpose of this library, which is to translate the user's keypresses into keysyms according to the keymap and the XKB specification. The tests emulate a series of key presses, and checks that the resulting keysyms are what we expect. Several of the tests currently fail, and plenty more should be added and maybe split up. It also currently uses an RMLVO keymap, which comes from the xkeyboard-config data set, and whose behaviour may change in the future. So it should probably be changed to use several files of our own, but it's OK for now. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 1c27bb8e 2012-06-06T00:19:48 Update .gitignore Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 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>
Ran Benita 40b56b0f 2012-05-07T14:23:08 Update .gitignore for automake 1.12 Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone 3e9dd751 2012-03-27T16:59:01 Add new context API Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita eeb0a214 2012-03-23T17:55:08 Update gitignore for 'state' test Signed-off-by: Ran Benita <ran234@gmail.com>
Gaetan Nadon ceba14dc 2010-12-07T10:23:18 config: update subdirs .gitignore Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Dan Nicholson c728d91b 2009-04-10T12:33:31 Program and files for testing CompileKeymapFromFile A few simple test cases for verifying the operation of parsing a keymap file and compiling a keyboard description from it.
Dan Nicholson 713c8f41 2009-04-04T12:54:44 test: Exercise compiling from components This could probably use a lot more real world test cases, but it does the job for now.
Dan Nicholson 8f9a6129 2009-04-04T10:52:23 test: Add logging and some intentionally failing cases We want to log the output of the tests rather than letting them go to stderr. This allows tests we expect to fail to be run.
Dan Nicholson 5cc55d7c 2009-04-04T09:14:20 Test compiler to simulate xkbcomp usage Added a test program, rulescomp, which takes a RMLVO set and generates a XkbcDescPtr. This is essentially what the xserver will do, except that we still need to access some xkbcomp internal API to make it work.
Dan Nicholson b2737e9b 2009-01-20T18:57:22 Testing harness for keysym functions A test program and script have been added for checking the XkbCommon keysym functions. This has already highlighted an error in handling of keysyms from XF86keysym.h.