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

21 lines
190 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
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>
2013-07-30 04:38:51 -06:00
interactive-evdev
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/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
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>
2013-07-30 06:06:40 -06:00
x11
interactive-x11
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>
2014-02-09 04:50:21 -07:00
utf8
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>
2014-08-09 13:14:34 -06:00
x11comp