StreetLight
/
libxkbcommon
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
libxkbcommon/test/.gitignore

18 lines
166 B
Plaintext
Raw Normal View History

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.
2009-04-04 11:52:23 -06:00
*.log
Update .gitignore for automake 1.12 Signed-off-by: Ran Benita <ran234@gmail.com>
2012-05-07 05:23:08 -06:00
*.trs
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.
2009-04-10 13:33:31 -06:00
filecomp
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.
2009-04-04 10:14:20 -06:00
rulescomp
Fix warning Signed-off-by: Ran Benita <ran234@gmail.com>
2012-08-08 16:55:30 -06:00
keysym
Update gitignore for 'state' test Signed-off-by: Ran Benita <ran234@gmail.com>
2012-03-23 09:55:08 -06:00
state
Add new context API Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-03-27 09:59:01 -06:00
context
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>
2012-05-18 17:35:15 -06:00
rules-file
Update .gitignore Signed-off-by: Ran Benita <ran234@gmail.com>
2012-06-05 15:19:48 -06:00
stringcomp
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
2013-03-11 05:53:39 -06:00
buffercomp
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>
2012-04-10 12:20:27 -06:00
keyseq
Add test for logging functionality Just to make sure everything works properly. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-07-22 10:38:14 -06:00
log
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
2012-04-07 17:20:39 -06:00
interactive
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>
2012-08-29 02:54:05 -06:00
rmlvo-to-kccgst
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>
2012-09-19 07:44:15 -06:00
print-compiled-keymap
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>
2012-10-24 15:27:40 -06:00
bench-key-proc
test/atom: add test for atom table Mostly a random test. Signed-off-by: Ran Benita <ran234@gmail.com>
2013-12-02 05:16:45 -07:00
atom