summaryrefslogtreecommitdiff
path: root/test
AgeCommit message (Collapse)AuthorFilesLines
2013-05-09Add keycode min/max and iteration APIMatthias Clasen1-0/+23
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>
2013-05-09Widen keycode range to 8/255 if possible (bug #63390)Daniel Stone1-0/+2
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>
2013-04-01keymap: add xkb_keymap_new_from_buffer()David Herrmann4-0/+109
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-04-01Add key-sequence checking to rulescompDaniel Stone1-60/+137
Make sure we're actually getting the keymaps we're hoping to compile. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2013-03-19test: Add va_list variant of test_key_seqDaniel Stone2-6/+17
For use when chaining tests. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2013-03-19Allow NULL rmlvo for xkb_keymap_new_from_namesDaniel Stone1-6/+10
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>
2013-03-19test: Add environment checking to rulescompDaniel Stone1-3/+45
To ensure that overriding RMLVO from the environment works. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2013-03-19test: Suppress RMLVO environment inheritance by defaultDaniel Stone2-1/+16
But add a flag to allow it for later usage. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2013-03-19Add environment overrides for default RMLVODaniel Stone1-7/+0
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>
2013-03-19test: Use test_get_context() in log.cDaniel Stone1-1/+1
Since the only behavioural change is overriding default includes. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2013-03-19test: Add flags argument to test_get_context()Daniel Stone13-13/+17
Allowing overriding of environment suppression, at first. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2013-03-19test: Move test_key_seq to common.cDaniel Stone3-104/+109
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2013-03-18keyseq: add a couple of testsRan Benita1-0/+29
Tests the filter refcounting. Signed-off-by: Ran Benita <ran234@gmail.com>
2013-03-18Don't try to build linux-specific tests on non-linuxRan Benita1-1/+0
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>
2013-03-18keymap: abstract a bit over the keymap formatRan Benita3-0/+26
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>
2013-03-18test/rmlvo-to-kccgst: free memory before exitRan Benita1-0/+6
Signed-off-by: Ran Benita <ran234@gmail.com>
2013-03-18keymap-dump: remove some ugly empty linesRan Benita1-3/+0
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>
2013-03-18keymap-dump: don't indent after xkb_keymap {Ran Benita1-1906/+1906
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>
2013-03-18keysym: print unicode keysyms uppercase and 0-paddedRan Benita2-24/+28
Use the same format as XKeysymToString. Signed-off-by: Ran Benita <ran234@gmail.com>
2013-03-18test/interactive: change variable name for 'xkb' to 'keymap'Ran Benita1-2/+3
Signed-off-by: Ran Benita <ran234@gmail.com>
2013-03-18state: fix unbound virtual modifier bugRan Benita2-1/+1543
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>
2013-03-18test/interactive: also print the levelRan Benita1-10/+7
Signed-off-by: Ran Benita <ran234@gmail.com>
2013-03-18test/keyseq: re-add de(neo) level5 testRan Benita1-6/+5
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>
2013-03-18Sync test data from xkeyboard-configRan Benita21-146/+573
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>
2012-11-07test/keysym: '\e' is non-standardRan Benita1-1/+1
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>
2012-11-05keysym-utf: also translate special keysyms like Tab and ReturnRan Benita1-2/+15
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>
2012-10-29test/keyseq: add test for setting depressed groupRan Benita1-0/+46
Tests the SetGroup action is working properly. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-10-29state, context: allow passing NULL to *_unref()Ran Benita1-0/+5
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>
2012-10-24test: add key processing benchmarkRan Benita2-0/+97
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-23test/interactive: use num_layouts_for_key()Ran Benita1-2/+3
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>
2012-10-22test/interactive: add option to show state changesRan Benita1-6/+43
Pass -c to see. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-10-22Split the mods, layout, leds parts of xkb_state_componentsRan Benita2-44/+56
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>
2012-10-16Add xkb_keysym_from_name() flags argument for case-insensitive searchDavid Herrmann2-8/+48
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>
2012-10-12Change log env vars to XKB_LOG_LEVEL/VERBOSITYRan Benita1-2/+2
A bit more consistent and descriptive. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-10-11Make xkb_keymap_num_leds return the index range instead of active countRan Benita2-2/+2
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>
2012-10-10stringcomp: test compilation of a dump of a keymap created from rulesRan Benita1-0/+12
This would have caught the regression fixed in 2ac319c. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-10-10keymap, state: don't assume led index < xkb_keymap_num_ledsRan Benita2-5/+32
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>
2012-10-09keysym: fix xkb_keysym_is_upper/lower() to work properlyRan Benita1-0/+29
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>
2012-10-06state: fix bad EFFECTIVE check in *_is_active()Ran Benita1-0/+9
This is a regression introduced in ed78fbcb30888cbfc6cd00. XKB_STATE_EFFECTIVE is just a OR of the other states, so using & here is completely wrong. So test/state shows for example: dumping state for LCtrl down: group English (US) (0): effective depressed latched locked mod Control (2): depressed latched locked dumping state for LCtrl + RAlt down: group English (US) (0): effective depressed latched locked mod Control (2): depressed latched locked mod Mod1 (3): depressed latched locked dumping state for RAlt down: group English (US) (0): effective depressed latched locked mod Mod1 (3): depressed latched locked dumping state for Caps Lock: group English (US) (0): effective depressed latched locked mod Lock (1): depressed latched locked led Caps Lock (0): active dumping state for Alt-Shift-+ group English (US) (0): effective depressed latched locked mod Shift (0): depressed latched locked mod Mod1 (3): depressed latched locked which is bogus. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-30parser: remove XkbCompMapList ruleRan Benita2-17/+0
This rule allows you to put several xkb_keymaps in one file. This doesn't make any sense: only the default/first can ever be used, yet the others are fully parsed as well. Different keymaps should just be put in different files. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-30test/interactive: allow -k to get any absolute pathRan Benita1-3/+15
Instead of looking for a keymap in test/data. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-30Don't use %z printf formatRan Benita1-2/+3
Some libc's don't support it. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-27test: add keycodes files which map directly to evdev codesRan Benita3-0/+1695
This is a proof-of-concept for the long key names. The keycodes in the file evdev-xkbcommon are autogenerated from linux/input.h, and uses the names given there; all of the previous names are aliased to the new names, so they continue to work with the symbols files, etc. You can try it with 'sudo ./test/interactive -r evdev-xkbcommon -n 0' The -n 0 means that we don't offset the evdev scan codes - just feed them directly. The -r evdev-xkbcommon just means to use a new rules file which makes us use the new keycodes file. (The only problem I can see is with the MENU and LSGT names which has some conflicts). Maybe some day xkeyboard-config could ship something similar, so that the 8 offset is unneeded. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-27keymap-dump: make it look better with long key namesRan Benita1-495/+495
Not worth messing around with too much, just make it legible. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-27test/interactive: allow to set evdev offsetRan Benita1-5/+13
If we want to test a keymap without the usual 8 offset. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-27Add xkb_state_key_get_one_symDaniel Stone1-0/+15
The trivial wrapper around xkb_state_key_get_syms that every user to date has implemented. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-09-24Add format argument to xkb_keymap_get_as_stringRan Benita2-2/+2
This function really needs a format argument, for symmetry with the keymap creation functions. If we add new formats, we will almost certainly want to add support for serializing it into a string. It would also allow to convert from one format to another, etc. The in the common case, the user would just want to use the format she used to create the keymap; for that we add a special XKB_KEYMAP_USE_ORIGINAL_FORMAT value, which will do that (it is defined to -1 outside of the enum because I have a feeling we might want to use 0 for something else). To support this we need to keep the format inside the keymap. While we're at it we also initialize keymap flags properly. This changes the API, but the old xkb_map_get_as_string name works as expected so this is the best time to do this. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-24API: add _context prefix to log-related functionsRan Benita3-18/+18
This is to follow the general scheme set by all of the other API functions. Since no one is using these functions yet, we don't (actually better not) add the old names to xkbcommon-compat.h. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-24state: correctly wrap state->locked_group and ->groupRan Benita1-0/+40
These values weren't wrapped before, which caused group_index_is_active to stop working after a few group switches. Also, the current group-wrapping function didn't take into consideration actions such as LockGroup=-1, which need to wrap around, etc. xkb_layout_index_t is unsigned, but it was used to hold possibly negative values (e.g. locked_group is 0 and gets a -1 action). This group wrapping function should now act like the XkbAdjustGroup function from xserver, and at least ./test/interactive doesn't bring up any problems with group switching any more. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-24Don't choke on RMLVO layout string with holesRan Benita1-0/+3
This old rules parser gives the same kccgst here, so in the interest of staying compatible we shouldn't fix it there. Similarly we shouldn't touch ParseIncludeMap, so this is the best place to handle this. Signed-off-by: Ran Benita <ran234@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-21 13:58:18 +0000