kc3-lang/libxkbcommon/test/keysym.c

test/keysym.c

Log

Author Commit Date CI Message
Pierre Le Marre 61d8ec67 2025-05-12T18:20:47 misc: Fix string format specifiers Ensure better portability.
Pierre Le Marre bc3e464b 2025-04-09T12:35:05 keysyms: Fix Unicode handling - `xkb_utf32_to_keysym`: Allow [Unicode noncharacters]. There is no requirement to drop them and this would be the only function of our API doing so. From the Unicode Standard 16.0, section 23.7 “Noncharacters”: > Applications are free to use any of these noncharacter code points > internally. They have no standard interpretation when exchanged > outside the context of internal use. However, they are not illegal > in interchange, nor does their presence cause Unicode text to be > ill-formed. > If a noncharacter is received in open interchange, an application is > not required to interpret it in any way. It is good practice, > however, to recognize it as a noncharacter and to take appropriate > action, such as replacing it with `U+FFFD` REPLACEMENT CHARACTER, > to indicate the problem in the text. The key part is: > an application is not required to interpret it in any way Since we handle the reverse conversion with `xkb_keysym_to_utf32` just fine, I do not see a good motivation to keep this asymmetry. This is the only function with a special case for these code points. - `xkb_keysym_from_name`: - Unicode format `UNNNN`: allow control characters C0 and C1 and use `xkb_utf32_to_keysym` for the conversion when `NNNN < 0x100`, for backward compatibility. - Numeric hexadecimal format `0xNNNN`: *unchanged*. Contrary to the Unicode format, it does not normalize any keysym values in order to enable roundtrip with `xkb_keysym_get_name`. Also added tests to ensure various properties and consistency. Note about *surrogates*: they are valid valid *code points* but invalid Unicode *scalar values*, i.e. they cannot be encoded in any Unicode encoding form (UTF-8, UTF-16, UTF-32). So their corresponding Unicode keysyms are valid, but: - cannot be used as input of `xkb_keysym_to_utf32` nor `xkb_keysym_to_utf8` - cannot result as output of `xkb_utf32_to_keysym`. Otherwise they are valid e.g. in the Unicode keysym notation. [Unicode noncharacters]: https://en.wikipedia.org/wiki/Universal_Character_Set_characters#Noncharacters
Pierre Le Marre 08d9a031 2025-04-08T06:31:33 Unicode: Make surrogate handling more explicit
Pierre Le Marre ca798d21 2025-04-08T16:21:46 keysyms: Pad Unicode keysyms only up to 4 digits Previously there was a distinction between keysyms with code points in BMP and the others: the former used a 4-padding while the latter used a 8-padding: e.g `U0001` vs `U00010000`. This is unnecessary and makes the reading harder. Let’s use the same padding for all: `U0001` and `U10000`. Parsing remains unchanged and would parse both paddings. Also added a test to check no explicit name can clash with Unicode notation.
Pierre Le Marre 47c2c820 2025-04-08T18:09:41 Add internal API to get all explicit names of a keysym
Ran Benita e120807b 2025-01-29T15:35:22 Update license notices to SDPX short identifiers + update LICENSE Fix #628. Signed-off-by: Ran Benita <ran@unusedvar.com>
Pierre Le Marre 842497d9 2025-01-22T16:46:11 clang-tidy: Fix implicit or incorrect integer casts
Ran Benita 8c071403 2025-01-21T10:40:03 test/keysym: fix comparison of integers of different signs ``` ../test/keysym.c:320:9: warning: comparison of integers of different signs: 'int' and 'unsigned long' [-Wsign-compare] 320 | U16_APPEND(cp_string, offset, ARRAY_SIZE(cp_string), cp, isError); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/unicode/utf16.h:396:47: note: expanded from macro 'U16_APPEND' 396 | } else if((uint32_t)(c)<=0x10ffff && (i)+1<(capacity)) { \ | ~~~~~^ ~~~~~~~~ ``` Signed-off-by: Ran Benita <ran@unusedvar.com>
Pierre Le Marre b9b4ab47 2024-12-09T09:21:01 keysyms: Add sharp S upper case mapping exception The case mapping `ssharp` ß ↔ `U1E9E` ẞ was added in 13b30f4f0dccc08dfea426d73570b913596ed602 but was broken: - For the lower case mapping it returned the keysym `0x10000df`, which is an invalid Unicode keysym. - For the upper case mapping it returned the upper Unicode code point rather than the corresponding keysym. It did accidentally enable the detection of alphabetic key type for the pair (ß, ẞ) though. However this detection was accidentally removed in 5c7c79970a2800b6248e829464676e1f09c5f43d (v1.7) with an attempt to fix the wrong keysym case mapping. Finally both the *lower* case mapping and the key type detection were fixed for good when we implemented the complete Unicode simple case mappings and corresponding tests in e83d08ddbc9851944c662c18e86d4eb0eff23e68. However, the *upper* case mapping `ssharp` → `U1E9E` remained disabled. Indeed, ẞ is a relatively recent addition to Unicode (2008) and had no official recommendation, until recently. So while the lower mapping ẞ→ß exists in Unicode, its converse upper mapping does not. Yet since 2017 the Council for German Orthography (Rat für deutsche Rechtschreibung) recommends[^1] ẞ as the capitalization of ß. Due to its stability policies, the Unicode Character Database (UCD) that we use to generate our keysym case mappings (via ICU) cannot update the simple case mapping of ß. Discussions are currently ongoing in the Unicode mailing list[^2] and CLDR[^3] about how to deal with the new recommended case mapping. However, the discussions are oriented on text-processing and compatibility mappings, while libxkbcommon is on a rather lower level. It seems that the slow adoption of ẞ is partly due to the difficulty to type it. Since ẞ is used only for ALL CAPS casing, the expectation is to type it using CapsLock. While our detection of alphabetic key types works well[^4] for the pair (ß,ẞ), the *internal capitalization* currently does not work and is fixed by this commit. Added the ß → ẞ upper mapping: - Added an exception in the generation script - Fixed tests - Added documentation of the exceptions in `xkbcommon.h` - Added/updated log entries [^1]: https://www.rechtschreibrat.com/regeln-und-woerterverzeichnis/ [^2]: https://corp.unicode.org/pipermail/unicode/2024-November/011162.html [^3]: https://unicode-org.atlassian.net/browse/CLDR-17624 [^4]: Except libxkbcommon 1.7, see the second paragraph.
Pierre Le Marre 378badab 2024-09-19T17:30:55 Add function xkb_keysym_is_deprecated This function allow to check whether a keysym is deprecated, based on the keysym and optionally its name. The generation of the table of deprecated keysyms relies on the rules described in `xkbcommon-keysyms.h`. The `ks_table.h` is now generated deterministically by setting explicitly the random seed to a constant. This will avoid noisy diffs in the future.
Pierre Le Marre e4269202 2024-09-20T10:41:00 keysyms: Fix off-by-one XKB_KEYSYM_NAME_MAX_SIZE The constant did not account for the terminating `NULL` byte and this was sadly not caught by the tests. Fixed the invalid value, the corresponding script and the tests.
Peter Hutterer 4b69cd9c 2024-07-16T10:48:32 test/keysym: remove dead assignment ../../../test/keysym.c:394:5: warning: Value stored to 'iter' is never read [deadcode.DeadStores] 394 | iter = xkb_keysym_iterator_unref(iter);
Pierre Le Marre e83d08dd 2024-02-23T17:10:15 keysyms: Fast and complete case mappings (Unicode 15.1) The current code to handle keysym case mappings is quite complex and slow. It is also incomplete, as it does not cover recent Unicode database. Finally, it does not handle title case correctly. It would be easier if we were to use only a lookup table, but a trivial implementation would lead to a huge array: the cased characters range from `U+0041` to `U+`1F189, i.e. a span of 127 304 elements. Thus we need some tricks to compress the lookup table. We based our work on the post: https://github.com/apankrat/notes/blob/3c551cb028595fd34046c5761fd12d1692576003/fast-case-conversion/README.md The compression algorithm is roughly: 1. Compute the delta between the characters and their mappings. 2. Split the delta array in chunk of a given size. 3. Rearrange the order of the chunks in order to optimize consecutive chunks overlap. 4. Create a data table with the reordered chunks and an index table that maps the original chunk index to its offset in the data table. The compression algorithm is then applied a second time to the previous index table. The complete algorithm optimizes the two chunk sizes in order to get the lowest total data size. The mappings were generated using CPython 3.12.4, PyICU 2.13, PyYaml 6.0.1 and ICU 75.1. Also: - Added explicit list of named keysyms and their case mappings. - Added benchmark for case mappings. - Rework ICU tests. Note: 13b30f4f0dccc08dfea426d73570b913596ed602 introduced a fix for sharp S `U+00DF`. With the new implementation, the *conversion* functions `xkb_keysym_to_{lower,upper}` leave it *unchanged*, while the *predicate* functions `xkb_keysym_is_{lower,upper_or_title}` produce the expected results: ```c xkb_keysym_to_upper(XKB_KEY_ssharp) == XKB_KEY_ssharp; xkb_keysym_to_lower(XKB_KEY_ssharp) == XKB_KEY_ssharp; xkb_keysym_to_lower(XKB_KEY_Ssharp) == XKB_KEY_ssharp; xkb_keysym_is_lower (XKB_KEY_ssharp) == true; xkb_keysym_is_upper_or_title(XKB_KEY_Ssharp) == true; ```
Pierre Le Marre addf73c5 2024-07-12T09:17:34 keysyms: Require only 5 bytes for UTF-8 encoding Require only 5 bytes for the buffer of `xkb_keysym_to_utf8`, as UTF-8 encodes code points on up to 4 bytes + 1 byte for the NULL-terminating byte. Previous standard [RFC 2279] (1998) required up to 6 bytes per code point, but has been superseded by [RFC 3629] (2003). [RFC 2279]: https://datatracker.ietf.org/doc/html/rfc2279 [RFC 3629]: https://datatracker.ietf.org/doc/html/rfc3629
Pierre Le Marre 53d9881e 2024-03-05T10:28:11 keysyms: Fix inconsistent case-insensitive name lookup `xkb_keysym_from_name` has inconsistent behavior when used with the flag `XKB_KEYSYM_CASE_INSENSITIVE`: ```c xkb_keysym_from_name("a", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_a; xkb_keysym_from_name("A", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_a; xkb_keysym_from_name("dead_a", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_dead_A; xkb_keysym_from_name("dead_A", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_dead_A; xkb_keysym_from_name("dead_o", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_dead_o; xkb_keysym_from_name("dead_O", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_dead_o; xkb_keysym_from_name("KANA_tsu", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_kana_tsu; xkb_keysym_from_name("KANA_TSU", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_kana_tsu; xkb_keysym_from_name("KANA_ya", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_kana_YA; xkb_keysym_from_name("KANA_YA", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_kana_YA; xkb_keysym_from_name("XF86Screensaver", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_XF86ScreenSaver; xkb_keysym_from_name("XF86ScreenSaver", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_XF86ScreenSaver; ``` So currently, if two keysym names differ only by case, then the lower-case *keysym* is returned, not the keysym corresponding to the lower-case keysym *name*. Indeed, `xkb_keysym_from_name` uses `xkb_keysym_is_lower` to test if a keysym is a lower-case keysym. Let’s look at the example for keysyms `a` and `A`: we get the keysym `a` not because its name is lower case, but because `xkb_keysym_is_lower(XKB_KEY_a)` returns true and `xkb_keysym_is_lower(XKB_KEY_A)` returns false. So the results are correct according to the doc: - Katakana is not a bicameral script, so e.g. `kana_ya` is *not* the lower case of `kana_YA`. - As for the `dead_*` keysyms, they are not cased either because they do not correspond to characters. - `XF86ScreenSaver` and `XF86Screensaver` are two different keysyms. But this is also very counter-intuitive: `xkb_keysym_is_lower` is not the right function to use in this case, because one would expect to check only the name, not the corresponding character case: ```c xkb_keysym_from_name("KANA_YA", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_kana_ya; xkb_keysym_from_name("XF86ScreenSaver", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_XF86Screensaver; ``` Fixed by making the order of the keysyms names consistent in `src/ks_tables.h`: 1. Sort by the casefolded name: e.g. `kana_ya` < `kana_YO`. 2. If same casefolded name, then sort by cased name, i.e for ASCII: upper before lower: e.g `kana_YA` < `kana_ya`. Thus we now have e.g. `kana_YA` < `kana_ya` < `kana_YO` < `kana_yo`. The lookup logic has also been simplified. Added exhaustive test for ambiguous case-insensitive names.
Pierre Le Marre e325e65e 2024-02-20T08:13:37 Add test_unit to all tests Currently it only ensure we do not buffer `stdout`.
Pierre Le Marre 382f6d2d 2024-02-05T08:57:35 Keysyms: Update using latest xorgproto For the sake of compatibility, this reintroduce some deleted keysyms and postpone the effective deprecation of others. xorgproto commit: fe12c5102762afcbf852e50dcbbdea2ef625570c Also added tests for some canonical names.
Pierre Le Marre c88fe4b6 2023-12-07T12:21:53 keysyms: Add tests with ICU Added tests of the simple case mappings when the ICU library is available. A warning is raised for missing mappings. Note: `xkb_keysym_is_upper` is interpreted as matching the disjunction of the Unicode character properties “Uppercase” or “Titlecase”.
Pierre Le Marre 82305adb 2023-12-05T18:23:02 keysyms: Test keypad
Pierre Le Marre b5a14083 2023-12-05T17:51:46 keysyms: Fix xkb_keysym_is_modifier Currently `xkb_keysym_is_modifier` does not detect the following keysyms: - `XKB_KEY_ISO_Level5_Shift` - `XKB_KEY_ISO_Level5_Latch` - `XKB_KEY_ISO_Level5_Lock` Indeed, there is a mistake in the keysym interval that the code checks. The reason seems a confusing order of the keysyms in `xkbcommon-keysyms.h`: the current code has a comment “libX11 only goes up to XKB_KEY_ISO_Level5_Lock”, but in fact the modifiers keysyms are listed in a _semantic_ order in `xkbcommon-keysyms.h`, not in the increasing keysym _value_ order. Fixed by using the same (correct) code as libX11 and added some tests.
Pierre Le Marre 0074baf4 2023-12-19T07:28:52 keysyms: Add XKB_KEYSYM_NAME_MAX_SIZE for internal use Currently there is no indication of the maximum length of keysym names. This is statically known, so add the new *internal* following API: `XKB_KEYSYM_NAME_MAX_SIZE`.
Pierre Le Marre f77c97bd 2023-12-14T08:19:31 keysyms: Test xkb_keysym_to_utf8 length
Pierre Le Marre 817179d8 2023-12-14T08:19:28 keysyms: Add xkb_keysym_iterator Add an efficient way to iterate over the assigned keysyms. Currently only provided for testing, so we guard it by `ENABLE_PRIVATE_APIS` in order to reduce the installed library.
Pierre Le Marre 4f52d606 2023-12-14T09:16:55 keysyms: Add xkb_keysym_is_assigned Add internal API `xkb_keysym_is_assigned` for tests, guarded by `ENABLE_PRIVATE_APIS` in order to avoid increasing the size of the installed library.
Pierre Le Marre 82f138c6 2023-12-14T09:13:35 keysyms: Add min and max assigned keysyms internal API Currently there is no direct way to know the minimum and maximum keysym values that are assigned, i.e. that have an explicit name or are Unicode keysyms. Introduce the new following internal API: - XKB_KEYSYM_MIN_ASSIGNED - XKB_KEYSYM_MAX_ASSIGNED - XKB_KEYSYM_MIN_EXPLICIT - XKB_KEYSYM_MAX_EXPLICIT - XKB_KEYSYM_COUNT_EXPLICIT Also add a bunch of tests to ensure consistant keysyms bounds.
Pierre Le Marre 4a92f61b 2023-12-14T08:19:16 keysyms: Add Unicode constants Add the following constants in order to improve the code readability: - XKB_KEYSYM_UNICODE_OFFSET - XKB_KEYSYM_UNICODE_MIN - XKB_KEYSYM_UNICODE_MAX
Pierre Le Marre a4c08526 2023-07-04T09:23:24 Improved tests related to keysyms - Add a keymap test with decimal and hexadecimal keysyms. - Reorganize code in `test/keysym.c` by parsing type: name, Unicode and hexadecimal. - Add more tests for edge cases. In particular: - test decimal format (currently not supported); - test the Unicode and hexadecimal ranges more thoroughly; - test with wrong case without the XKB_KEYSYM_CASE_INSENSITIVE flag; - test surrounding spaces. - Document the tests.
Pierre Le Marre 183761ac 2023-05-13T17:26:24 Do not interpret nor emit invalid Unicode encoding forms Surrogates are invalid in both UTF-32 and UTF-8. See https://www.unicode.org/versions/Unicode15.0.0/ch03.pdf#G28875 and https://www.unicode.org/versions/Unicode15.0.0/ch03.pdf#G31703
Sam Lantinga 25367130 2022-04-27T18:45:54 Remove bogus euro sign entry from keysymtab Not sure what it's doing here, but converting "€" to a keysym doesn't work with this entry. 0x13a4 doesn't appear in xkbcommon-keysyms.h. 0x20ac is the keysym documented in the header (and it's the last entry in the table). It's been in the table since it was introduced in e0524296d2e0 ("Add API for getting unicode representation of a keysym"). Co-authored-by: Simon Ser <contact@emersion.fr>
Isaac Freund 68dddd41 2021-04-22T00:37:03 keysym: fix underflow in binary searches This is hit when passing an empty string and XKB_KEYSYM_CASE_INSENSITIVE to xkb_keysym_from_name currently if `(lo + hi) / 2` is 0 and `cmp < 0`, causing mid to underflow and the the array access into name_to_keysym on the next iteration of the loop to be out of bounds . We *would* use ssize_t here as it is the appropriate type, but windows unfortunately does not define it.
Ran Benita 8cd688c0 2021-04-01T22:07:28 keysym: avoid strtoul in xkb_keysym_from_name Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita 1c0e28ad 2021-03-30T19:11:59 keysym: properly handle overflow in 0x keysym names Relatedly, strtoul allows a lot of unwanted stuff (spaces, +/- sign, thousand seperators), we really ought not use it. But that's for another time. Signed-off-by: Ran Benita <ran@unusedvar.com>
Peter Hutterer d1726527 2021-03-30T08:08:58 test: move an assert up to before the strlen() use ../../../test/keysym.c:80:24: warning: Null pointer passed to 1st parameter expecting 'nonnull' [core.NonNullParamChecker] (unsigned) strlen(expected)); Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Jaroslaw Kubik 0345aba0 2020-02-12T23:44:42 Support translation Unicode codepoints to keysyms In order to support features like auto-type and UI automation, the relevant tools need to be able to invert the keycode->keysym->text transformation. In order to facilitate that, a new API was added. It allows querying the keysyms that correspond to particular Unicode codepoints. For all practical purposes, it can be thought of as an inverse of xkb_keysym_to_utf32().
Ran Benita 40aab05e 2019-12-27T13:03:20 build: include config.h manually Previously we included it with an `-include` compiler directive. But that's not portable. And it's better to be explicit anyway. Every .c file should have `include "config.h"` first thing. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita 5cee660f 2018-06-23T22:00:19 keysym-utf: reject out-of-range Unicode codepoints in xkb_keysym_to_utf{8,32} It used to be UTF-8 was defined for inputs > 0x10FFFF, but nowadays that's the maximum and a codepoint is encoded up to 4 bytes, not 6. Fixes: https://github.com/xkbcommon/libxkbcommon/issues/58 Fixes: https://github.com/xkbcommon/libxkbcommon/issues/59 Reported-by: @andrecbarros Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita b5586a6c 2016-12-02T22:15:19 keysym: fix locale dependence in xkb_keysym_from_name() We currently use strcasecmp, which is locale-dependent. In particular, one well-known surprise even if restricted just ASCII input is found in the tr_TR (Turkish) locale, see e.g. https://msdn.microsoft.com/en-us/library/ms973919.aspx#stringsinnet20_topic5 We have known to avoid locale-dependent functions before, but in this case, we forgot. Fix it by implementing our own simple ASCII-only strcasecmp/strncasecmp. Might have been possible to use strcasecmp_l() with the C locale, but went the easy route. Side advantage is that even this non-optimized version is faster than the optimized libc one (__strcasecmp_l_sse42) since it doesn't need to do the locale stuff. xkb_keysym_from_name(), which uses strcasecmp heavily, becomes faster, and so for example Compose file parsing, which uses xkb_keysym_from_name() heavily, becomes ~20% faster. Resolves https://github.com/xkbcommon/libxkbcommon/issues/42 Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 1499eedd 2013-08-13T18:52:46 keysym: add xkb_keysym_to_{lower,upper} These functions are needed later; they are not API functions. The capitalization is not locale sensitive. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita c7aef166 2013-02-19T15:57:14 keysym: print unicode keysyms uppercase and 0-padded Use the same format as XKeysymToString. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita d87035ad 2012-11-07T18:58:18 test/keysym: '\e' is non-standard 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>
Ran Benita 7891c917 2012-11-05T21:34:59 keysym-utf: also translate special keysyms like Tab and Return 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>
David Herrmann 7b3bd11f 2012-10-16T16:05:34 Add xkb_keysym_from_name() flags argument for case-insensitive search 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>
Ran Benita 9179fed7 2012-10-09T20:48:35 keysym: fix xkb_keysym_is_upper/lower() to work properly 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>
Ran Benita b2110705 2012-09-16T14:45:32 Organize src/ and test/ headers - Add context.h and move context-related functions from xkb-priv.h to it. - Move xkb_context definition back to context.c. - Add keysym.h and move keysym upper/lower/keypad from xkb-priv.h to it. - Rename xkb-priv.h to map.h since it only contains keymap-related definitions and declarations now. - Remove unnecessary includes and some and some other small cleanups. Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone b4b40d73 2012-09-12T16:54:07 Copyright updates With Dan Nicholson's permission (via email), update his copyright and license statements to the standard X.Org boilerplate MIT license, as both myself and Ran have been using. Clean up my copyright declarations (in some cases to correct ownership), and add copyright/license statements from myself and/or Ran where appropriate. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 6021a976 2012-08-03T03:45:14 test: Minimise includes Mostly from functions which used to use file functions directly, but now use test.h wrappers. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 8fe2a484 2012-08-03T03:32:30 Rename xkey test to keysym Signed-off-by: Daniel Stone <daniel@fooishbar.org>
kmx.io     mail     discord kmxgit v0.4.0