Branch :
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
| 7036e46c | 2025-01-13 15:20:47 | symbols: Add tests for key merge modes (keysyms/actions) This commit adds tests for merging various key configurations: - With/without keysyms/actions - Single/multiple keysyms/actions per level We test all the merge modes for including a map (global) as well as directly on the keys (local): - default (global: include, local: implicit) - augment - override - replace The tests data are generated with: - A Python script `scripts/update-merge-modes-tests.py` for keycodes and symbols data. Use `--debug` for extra comments to help debugging. The script can optionally generate C headers for alternative key sequence tests, that were used before implementing golden tests. The latter tests are not used anymore (duplicate with golden tests) but their generator is kept for now, as they can still be useful for debugging or writing similar tests. - The `merge-modes` test generates its own keymap files for golden tests, using: `build/test-merge-modes update`. It can also replace them with the obtained output rather than the expected one using `build/test-merge-modes update-obtained`, which is very useful for debugging. | ||
| 00e3058e | 2023-11-06 21:53:51 | Prevent recursive includes of keymap components - Add check for recursive includes of keymap components. It relies on limiting the include depth. The threshold is currently to 15, which seems reasonable with plenty of margin for keymaps in the wild. - Add corresponding new log message `recursive-include`. - Add tests for recursive includes. | ||
| 87dcf301 | 2023-09-28 09:51:25 | Fix trailing whitespaces in XKB files | ||
| 1c352199 | 2020-09-07 11:35:22 | test/data: sync from xkeyboard-config 2.30 Signed-off-by: Ran Benita <ran@unusedvar.com> | ||
| c6ee6371 | 2014-10-16 17:48:00 | test/data: sync to xkeyboard-config 2.13 (Run ./test/data/sync.sh). Signed-off-by: Ran Benita <ran234@gmail.com> | ||
| 9cef902d | 2013-08-14 11: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> | ||
| e731b251 | 2013-08-01 20: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> | ||
| 92e07726 | 2012-09-27 20:16:12 | test: add keycodes files which map directly to evdev codes 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> | ||
| 7ef359de | 2012-08-12 18:16:52 | rulescomp: remove bad failtests Since we now handle empty model/layout, the last couple of tests should not fail. The reason they do is bacause they try to use a non-existent "base" rules file. When the file is brought in these tests do not fail. Since we already test for non-existent rules file, we can remove them, and refine the other tests a bit. Signed-off-by: Ran Benita <ran234@gmail.com> | ||
| 62deaeb5 | 2012-07-12 14:42:31 | Import dataset into test/data/ Use a self-contained dataset instead of relying on a globally-installed set. Data taken from xkeyboard-config 2.5.1. Signed-off-by: Daniel Stone <daniel@fooishbar.org> |