|
0106b357
|
2025-06-17T12:06:32
|
|
registry: Add rxkb_option_is_layout_specific()
Enable to query if an option accepts layout index specifiers to restrict
its application to the corresponding layouts.
|
|
c4c531da
|
2025-06-17T11:43:50
|
|
rules: Add layout-specific options for RMLVO builder
Change the signature of `xkb_rmlvo_builder_append_layout()` to accept
an array of options.
Also add tests for layout-specific options.
|
|
fab9d25b
|
2025-06-17T11:43:22
|
|
rules: Add support for layout-specific options
Enabled specifying a layout index for each option, so that it applies
only if the layout matches. The layout index is specified by appending
immediately after the option name the `!` specifier delimiter and then
the layout index, in decimal form and 1-indexed.
Note that `!` was chosen instead of the usual `:` specifier delimiter,
because some options contains `:`, e.g. `grp:menu_toggle`. `!` *cannot*
clash with component names, because `!` is a token in the rules files
and thus cannot be used as in component names. It is also vaguely similar
to `:`, compared to e.g. `@` or `#`.
Example: given the following rules:
! layout[any] option = symbol
* opt1 = +s1:%i
l2 opt2 = +s2:%i
it may result in the following configurations:
| Layout | Option | Symbols |
| -------- | -------- | ------------ |
| `l1` | `opt1` | `+s1:1` |
| `l2` | `opt1` | `+s1:1` |
| `l1` | `opt2` | `` |
| `l2` | `opt2` | `+s2:1` |
| `l1,l2` | `opt1` | `+s1:1+s1:2` |
| `l1,l2` | `opt1!1` | `+s1:1` |
| `l1,l2` | `opt1!2` | `+s1:2` |
| `l1,l2` | `opt2` | `+s2:2` |
| `l1,l2` | `opt2!1` | `` |
| `l1,l2` | `opt2!2` | `+s2:2` |
|
|
ef6a550f
|
2025-06-16T15:48:25
|
|
Add xkb_keymap_new_from_rmlvo()
Use the new RMLVO builder API to compile keymaps.
|
|
da5caabb
|
2025-06-16T15:45:42
|
|
Add RMLVO builder API
Before this commit, the API to work with RMLVO was quite minimal: it
only uses raw strings from the `xkb_rule_names` struct. However:
- it forces the users to deal with error-prone string formatting;
- it does not enforce tying together layouts and variants;
- it limits adding new features by requiring defining delimiter
characters and the corresponding parsing.
Added the following API:
- `xkb_rmlvo_builder_new()`
- `xkb_rmlvo_builder_append_layout()`
- `xkb_rmlvo_builder_append_option()`
- `xkb_rmlvo_builder_unref()`
There is no intermediate `layout` nor `option` object, in order to
to keep the API simple. The only foreseen extension is enabling
configuring layout-specific options.
|
|
58397e94
|
2025-05-06T18:05:30
|
|
Deprecate xkb_keymap_new_from_names()
- Deprecate `xkb_keymap_new_from_names()` in favor of
`xkb_keymap_new_from_names2()`
- Add new changelog fragment type `deprecated`.
- Change documentation to use the new function.
|
|
1a10f858
|
2025-05-06T18:05:06
|
|
Add xkb_keymap_new_from_names2
This is just `xkb_keymap_new_from_names()` with an explicit keymap
format.
|
|
27ba56ae
|
2025-05-07T10:55:24
|
|
doc: Add initial documention for XKB_KEYMAP_FORMAT_TEXT_V2
|
|
44c8deb2
|
2025-05-07T10:20:25
|
|
Introduce keymap format v2 and make it the default for parsing
- Added `XKB_KEYMAP_FORMAT_TEXT_V2`.
- Made `xkb_keymap_new_from_names()` use the new keymap format.
- Made the tools default to the new keymap format for input.
This is in preparation for changes in the parsing & state handling.
For now it changes nothing.
|
|
7a2aa9c9
|
2024-12-20T22:53:11
|
|
Always retain later Compose sequence in case of conflict
This ensures that it is always possible to override previous definitions,
for example when `include`ing the system Compose file.
Signed-off-by: Jules Bertholet <julesbertholet@quoi.xyz>
|
|
551cca2a
|
2024-12-03T10:12:03
|
|
state: Add server API for updating latched and locked mods & layout
Up to now, the “server state” `xkb_state` API only offered one entry
point to update the server state – `xkb_state_update_key`, which reflects
the direct keyboard keys state. But some updates come out-of-band from
keyboard input events stream, for example, a GUI layout switcher.
The X11 XKB protocol has a request which allows for such updates,
`XkbLatchLockState`[^1], but xkbcommon does not have similar
functionality. So server applications ended up using
`xkb_state_update_state` for this, but that’s a function intended for
client applications, not servers.
Add support for updating the latched & locked state of the mods and
layout. Note that the depressed states cannot be updated in this way --
XKB does not expect them to be updated out of band.
[^1]: https://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html#Querying_and_Changing_Keyboard_State
Fixes: #310
Signed-off-by: Ran Benita <ran@unusedvar.com>
Co-authored-by: Ran Benita <ran@unusedvar.com>
Co-authored-by: Pierre Le Marre <dev@wismill.eu>
|
|
7cd1180b
|
2025-05-06T11:07:47
|
|
modifiers: Add xkb_keymap_mod_get_mask()
Added a dedicated API to query modifier masks rather than relying on
a hack using `xkb_state_update_mask` and `xkb_state_serialize_mods`.
Furthermore, this hack may not work in the future if we remove virtual
mods resolution in `xkb_state_update_mask` to avoid corner-cases issues.
|
|
9fab3948
|
2025-05-09T00:05:31
|
|
doc: Deprecate legacy modifiers names
The following modifiers names in `xkbcommon/xkbcommon-names.h` are now deprecated:
- `XKB_MOD_NAME_ALT`: use `XKB_VMOD_NAME_ALT` instead.
- `XKB_MOD_NAME_LOGO`: use `XKB_VMOD_NAME_SUPER` instead.
- `XKB_MOD_NAME_NUM`: use `XKB_VMOD_NAME_NUM` instead.
|
|
51c8c5b5
|
2025-05-09T00:04:42
|
|
doc: Common modifiers & LEDs names
|
|
9ffe3cfc
|
2025-04-29T12:48:10
|
|
doc: Create a FAQ page
- Initialize with multiple recurrent questions.
- Document how to get the vmod → rmod mapping.
Rational: Some applications may need it to interface with legacy
code.
|
|
9ede705b
|
2025-04-13T09:50:18
|
|
state: Capitalization transformation in xkb_state_key_get_syms
Previously `xkb_state_key_get_syms()` did not perform capitalization
tranformation, while `xkb_state_key_get_one_sym()` does perform it.
This is unfortunate if we want to promote the use of multiple keysyms
per levels.
The API make it difficult to change now though: we return a pointer to
an immutable array rather than filling a buffer. While we could use an
internal buffer in `xkb_state`, this option would limit the API to
*sequential* calls of `xkb_state_key_get_syms()` or require some buffer
handling (e.g. rotation).
Instead we now store the capitalization directly in `xkb_level`. We
modified `xkb_level` like so (see below for discussion about the size):
```diff
struct xkb_level {
- unsigned int num_syms;
+ uint16_t num_syms;
- unsigned int num_actions;
+ uint16_t num_actions;
+ union {
+ /** num_syms == 1: Upper keysym */
+ xkb_keysym_t upper;
+ /** num_syms > 1: Indicate if `syms` contains the upper case
+ * keysyms after the lower ones. */
+ bool has_upper;
+ };
union {
xkb_keysym_t sym; /* num_syms == 1 */
xkb_keysym_t *syms; /* num_syms > 1 */
} s;
union {
union xkb_action action; /* num_actions == 1 */
union xkb_action *actions; /* num_actions > 1 */
} a;
};
```
- When `level.num_syms` <= 1, we store the upper keysym in `level.upper`.
- Else if there no cased syms, we set `level.has_upper` to false.
- Else if there are some cased syms, we set `level.has_upper`` to `true`
and we double the original size of `level.s.syms`, but *without*
modifying `level.num_syms`. We then append the transformed keysyms
right after the original ones, so that we can access them by a simple
pointer operation: `level.s.syms + level.num_syms`.
The memory footprint is *unchanged*, thanks to the reduced fields for
actions and keysyms counts.
|
|
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
|
|
8e92f25e
|
2025-03-13T21:26:59
|
|
rules: Added xkb_components_names_from_rules()
This is mainly for debugging purposes and to enable displaying KcCGST
values from RMLVO resolution in `xkbcli compile-keymap --kccgst`.
|
|
f3a4eeaa
|
2025-03-26T16:04:39
|
|
symbols: Improve keysym parsing
|
|
2fb1b2e1
|
2025-01-25T06:18:59
|
|
Make XKB_EXPORT do dllexport on Windows
Without this, the test-internal libraries (which don't use the .def file
because they contain additional private symbols) can't be made shared.
But it also makes sense for consistency with GCC.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
a380ba52
|
2025-01-25T07:00:43
|
|
Move XKB_EXPORT to headers
The Windows dllexport annotation wants to be on the declarations, not
the definitions.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
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>
|
|
0c940827
|
2025-01-22T16:39:35
|
|
clang-tidy: Macro arguments should be enclosed in parentheses
|
|
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.
|
|
e0130e30
|
2024-11-18T20:08:56
|
|
state: Add vmod support for xkb_state_mod_mask_remove_consumed
|
|
5fbc0ec7
|
2024-10-14T16:05:52
|
|
state: Support querying whether virtual mods are consumed
Previously it was not possible to query the status of virtual modifiers
with the following functions:
- `xkb_state_mod_index_is_consumed`
- `xkb_state_mod_index_is_consumed2`
Note that it may *overmatch* if some modifier mappings overlap. For
example, the default “us” PC layout maps both “Alt” and “Meta” to the
real modifier “Mod1”; thus “Mod1”, “Alt” and “Meta” modifiers will
return the same result with these functions.
|
|
31a841ae
|
2024-10-14T16:05:35
|
|
state: support querying whether virtual modifiers are active
Previously it was not possible to query the status of virtual modifiers
with the following functions:
- `xkb_state_mod_index_is_active`
- `xkb_state_mod_indices_are_active`
- `xkb_state_mod_name_is_active`
- `xkb_state_mod_names_are_active`
Note that it may *overmatch* if some modifier mappings overlap. For
example, the default “us” PC layout maps both “Alt” and “Meta” to the
real modifier “Mod1”; thus “Mod1”, “Alt” and “Meta” modifiers will
return the same result with these functions.
|
|
2ba9daf1
|
2024-09-23T16:20:37
|
|
mods: Add more built-in names
Added support for the following virtual modifiers:
- `Alt`
- `Meta`
- `NumLock`
- `Super`
- `Hyper`
- `LevelThree`
- `LevelFive`
- `ScrollLock`
|
|
086a286a
|
2024-09-23T16:20:17
|
|
mods: Always use constants from xkbcommon-names.h
Respect the claim that real modifiers names are built-in:
- Add `XKB_MOD_NAME_MOD[1-5]` constants.
- Replace modifiers names with their corresponding constants.
|
|
43b26bd7
|
2024-11-29T08:51:41
|
|
keysyms: Update to Unicode 16.0
|
|
1d897502
|
2024-10-04T08:09:28
|
|
keysyms: Update using latest xorgproto
xorgproto commit: d7ea44d5f04cc476dee83ef439a847172f7a6bd1
Relevant MR: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/91
|
|
9af1f9f2
|
2024-09-02T14:18:21
|
|
Add XKB_LED_NAME_COMPOSE and XKB_LED_NAME_KANA
|
|
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;
```
|
|
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
|
|
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.
|
|
ed2dc978
|
2024-02-08T07:41:39
|
|
keysyms: Update using latest xorgproto
This fixes a typo and improves comments.
xorgproto commit: cd33097fc779f280925c6d6bbfbd5150f93ca5bc
Relevant MR: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/84
|
|
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.
|
|
238d1324
|
2023-09-29T11:33:28
|
|
Keysyms: Fix missing hpYdiaeresis
The handling of keysym name guards (e.g. `#ifndef XK_Ydiaeresis`) was
incomplete and led to a missing keysym.
Make `sripts/makeheader` more robust to C macros handling.
|
|
49690d93
|
2023-09-28T07:18:56
|
|
Keysyms: Update using latest xorgproto
xorgproto commit: 1c8128d72df22843a2022576850bc5ab5e3a46ea.
|
|
a1770132
|
2023-09-25T11:41:48
|
|
Compose: add iterator API
Allow users to iterate the entries in a compose table. This is useful
for other projects which want programmable access to the sequences,
without having to write their own parser.
- New API:
- `xkb_compose_table_entry_sequence`;
- `xkb_compose_table_entry_keysym`;
- `xkb_compose_table_entry_utf8`;
- `xkb_compose_table_iterator_new`;
- `xkb_compose_table_iterator_free`;
- `xkb_compose_table_iterator_next`.
- Add tests in `test/compose.c`.
- Add benchmark for compose traversal.
- `tools/compose.c`:
- Print entries instead of just validating them.
- Add `--file` option.
- TODO: make this tool part of the xkbcli commands.
Co-authored-by: Pierre Le Marre <dev@wismill.eu>
Co-authored-by: Ran Benita <ran@unusedvar.com>
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
8c7076a0
|
2023-07-04T09:23:23
|
|
Improve the documentation of keysyms in xkbcommon.h
|
|
e811743f
|
2023-07-04T09:23:23
|
|
Add XKB_KEYSYM_MIN and XKB_KEYSYM_MAX
Keysyms are 32-bit integers with the 3 most significant bits always set
to zero. See: Appendix A “KEYSYM Encoding” of the X Window System
Protocol at https://www.x.org/releases/current/doc/xproto/x11protocol.html#keysym_encoding.
Add a new constants XKB_KEYSYM_MIN and XKB_KEYSYM_MAX to make the
interval of valid keysyms more obvious in the code.
|
|
0e9c2ec9
|
2023-04-30T21:30:36
|
|
Improve the doc of the XKB keymap text format, V1 (#321)
- Add table of contents
- Add terminology section
- (WIP) Add Introduction to the format
- Improve the keycode section
- Improve the interpret section
- Add guide to create and use modifiers
- (WIP) Add actions documentation
- Add cross-references
- Add keysyms header to documentation
|
|
003fdee1
|
2023-04-11T22:49:58
|
|
keysyms: add new keysyms XF86EmojiPicker, XF86Dictate
Ref: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/commit/914d8f5e0f469cd0416364dd008e9eea752bf703
Ref: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/commit/a839f0c7fc5596d10e786394d3b0953eb8a1731b
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
5ba075ab
|
2022-12-17T13:51:10
|
|
doc: clarify "server state" and "client state" distinction
Add a common page for the concept and link to there from the relevant
functions.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
b4e81ca1
|
2022-12-16T01:26:25
|
|
context: add XKB_CONTEXT_NO_SECURE_GETENV flag (#312)
This flag is useful for clients that may have relatively benign capabilities
set, like CAP_SYS_NICE, that also want to use the xkb configuration from the
environment and user configs in XDG_CONFIG_HOME.
Fixes: https://github.com/xkbcommon/libxkbcommon/issues/308
Fixes: https://github.com/xkbcommon/libxkbcommon/issues/129
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
a2507c08
|
2022-02-24T10:48:50
|
|
Improve misleading comments #270
|
|
7062ab97
|
2021-05-22T19:36:22
|
|
xkbcommon: deprecate XK_approxeq and XK_notapproxeq
Sync xorg-proto commit
https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/commit/25f3278b85ec7d1c78bb150eaea52f9c98294ea4
Fixes: #82
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
de1b6943
|
2021-04-27T10:10:26
|
|
Move include files to include/ subdirectory
This way we don't specify `include_directorories('.')` which brings in
more than needed.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
5e164ff1
|
2012-07-23T00:41:27
|
|
build: drop the include/ directory
The include/ dir is somewhat redundant and makes it just a bit harder to
handle the -I directives from out side of automake; without it the
default $(top_buildir) just works.
Here's also some further justifications I found:
http://smcv.pseudorandom.co.uk/2008/09/pc-uninstalled/
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
9308a460
|
2012-07-17T10:20:15
|
|
Run source tree through uncrustify
.uncrustify.cfg committed for future reference also, but had to manually
fix up a few things: it really likes justifying struct initialisers.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
1f492901
|
2012-07-11T18:00:31
|
|
Enlarge keysym name buffers and mention in comment
The longest keysym is 27 chars long.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
8e2c66e9
|
2012-06-22T15:27:05
|
|
Add xkb_key_repeats
Does what it says on the box.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
58b030bb
|
2012-05-20T20:39:35
|
|
Move XKB_KEY_NoSymbol to xkbcommon-keysyms.h
This avoids a couple of special cases in the code, and is more
consistent. Since anyone who includes xkbcommon.h also gets
xkbcommon-keysyms.h, and anyone who include xkbcommon-keysyms.h would
want NoSymbol anyway, there's no down side.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
e0524296
|
2012-06-08T13:10:28
|
|
Add API for getting unicode representation of a keysym
This code uses a table and code derived from
http://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c
The added API calls are:
xkb_keysym_to_utf32
xkb_keysym_to_utf8
[daniels: Changed API to be more in line with keysym_get_name, added
test, changed formatting to 4-space.]
|
|
ebd397e1
|
2012-05-25T17:05:39
|
|
Add xkb_map_get_as_string
Returns a newly-allocated string representing the specified keymap.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
b89b8e70
|
2012-05-13T23:31:59
|
|
Change xkb_map_new_from_fd to use FILE*
i.e. xkb_map_new_from_file. The reason is that flex only works with
FILE's, so we must use fdopen on the file descriptor; but to avoid a
memory leak, we must also fclose() it, which, in turn, closes the file
descriptor itself.
Either way is not acceptable, so we can either:
* dup() the fd and use fdopen on that, or
* have the user call fdopen on his own, and accept a FILE* instead of an
fd.
The second one seems better, and is standard C, so why not. We must add
stdio.h to xkbcommon.h though, which is regrettable, but not a big deal.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
7b00485a
|
2012-05-11T15:03:43
|
|
Rename 'ctx' back to 'context' in external API
Still keep things as 'ctx' internally so we don't have to worry about
typing it too often, but rename the user-visible API back as it was
kinda ugly.
This partially reverts e7bb1e5f.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
471e1122
|
2012-05-09T20:52:33
|
|
Document that xkb_state_get_map doesn't take a ref
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
7a1201bd
|
2012-05-09T20:51:37
|
|
Change xkb_key_get_syms to just return a bare int
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
46441b11
|
2012-05-09T20:49:04
|
|
Move KcCGST API to internal-only
And don't export it. We don't need it for X11 support, let alone
anything else.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
2761b1a3
|
2012-05-09T20:20:12
|
|
Rename serialise to serialize
Yes, British English is correct, but unfortunately we've lost that
battle.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
5a3771d1
|
2012-05-09T20:18:30
|
|
Add common LED names to xkbcommon-names.h
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
693d0578
|
2012-05-09T20:17:13
|
|
Include xkbcommon-names.h from xkbcommon.h
So clients only have one file to include.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
3e3ddd43
|
2012-05-09T20:12:18
|
|
Remove keycode_range_is_legal
It was a pretty pointless check. Also sanitise the _x11 variant to
actually do what it says on the box.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
6433d72e
|
2012-05-09T20:12:12
|
|
Merge remote-tracking branch 'krh/keysyms'
Conflicts:
src/keysym.c
src/misc.c
src/text.h
src/xkbcomp/expr.c
src/xkbcomp/parser.y
src/xkbcomp/parseutils.c
src/xkbcomp/symbols.c
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
c6897d26
|
2012-05-09T08:33:04
|
|
Add XKB version of X11 keysyms
With this we're now completely standalone.
add vendor keysyms
|
|
ace1e5df
|
2012-05-09T09:05:00
|
|
Use our own keysyms
|
|
e7bb1e5f
|
2012-05-09T15:03:11
|
|
Shorten context to ctx
(This breaks the API.)
"context" is really annoying to type all the time (and we're going to
type it a lot more :). "ctx" is clear, concise and common in many other
libraries. Use it!
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Fix for xkb -> keymap change.]
|
|
38cb6390
|
2012-05-09T15:15:30
|
|
Change all 'xkb' xkb_keymap names to 'keymap'
To make it a bit more clear what it actually is.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
e1af48bc
|
2012-05-09T13:22:34
|
|
Rename keysym <-> string API
Change them to refer to the string representation of the keysym's name
as a name rather than a string, since we want to add API to get the
Unicode printable representation as well.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
124e62e4
|
2012-05-09T01:06:10
|
|
Add multiple modifier state matching API
Two new calls allow users to test the exact modifier state, including
verifying that no other modifiers but the ones you wanted are down.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
74a197d2
|
2012-05-08T17:59:35
|
|
Add pre-defined names database
xkbcommon-names.h right now just contains a set of hardcoded modifier
strings that are most commonly used for the usual modifiers. Provide
definitions of these so people don't have to worry about typoing a
string or mixing up Mod1 and Mod4.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
2a0f1780
|
2012-05-08T17:52:45
|
|
Add context flag to inhibit default include paths
Which will make the context start with no include paths at all.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
c3584280
|
2012-05-08T17:51:16
|
|
Add flags to context creation
None defined as yet, but why not.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
b537b552
|
2012-05-08T17:48:29
|
|
Add flags to keymap compilation entrypoints
No use as yet, but might as well ...
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
b41c77f8
|
2012-05-07T14:54:12
|
|
Revert "Unconstify xkb_rules_names"
This reverts commit d007cd0a1f3f4b9c927175771ff79aae6fe4ab8b.
This is in fact more restrictive, because it breaks the (common) case
where the strings are const themselved, e.g. "evdev", "us", etc. As is
you must either duplicate the strings or suppress the warnings.
If the user needs to retain the non-const strings, he should instead
just keep them in some other struct and use xkb_rules_names just as
a temporary parameter for xkb_map_new_from_names. Mildly annoying but
acceptable.
|
|
1b9635df
|
2012-04-08T02:08:37
|
|
Add xkb_state_get_map()
This is very useful because it avoids redundent pointers in structs
and/or parameter passing in the application.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
18e6a6a4
|
2012-04-05T10:47:43
|
|
Remove Xfuncproto.h and XKB.h from xkbcommon/xkbcommon.h
The kbproto header is already not needed here anymore.
Move the _X_EXPORT's to the corresponding function definitions, and use
straight extern "C" clauses instead of _XFUNCPROTOBEGIN/END.
It also makes more sense to have the EXPORT's in the source files, as it
provides some documentation to the reader, whereas in the header it's
obvious.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb_keymap changes.]
|
|
073a2107
|
2012-04-08T15:40:12
|
|
Constify the syms_out argument to xkb_key_get_syms()
The caller should not mess around with these as they come directly from
our internal structs.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
467d7bb6
|
2012-04-05T10:13:24
|
|
Implement missing xkb_state_ref and add return value
xkb_state_ref was missing.
Also modify the _ref functions to return the object instead of being
void. This is a useful idiom:
struct my_object my_object_new(struct xkb_state *state)
{
[...]
my_object->state = xkb_state_ref(state);
[...]
}
Essentially "taking" a reference, such that you don't forget to
increment it and it's one line less (see example in our own code).
A case could also be made for _unref to return the object or NULL, but
this is quite uncommon.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb_keymap changes.]
|
|
2590b5a1
|
2012-04-08T15:37:36
|
|
Fix compiler warnings
(They were not reported, see next commit).
The reset function declaration didn't match its name in the definition;
the _defaults variant matches better with the rest.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated to current master.]
|
|
ef88c7ef
|
2012-04-03T15:14:16
|
|
Rename xkb_desc to xkb_keymap
struct xkb_desc was just a hangover from the old XkbDescRec, which isn't
a very descriptive name.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
d007cd0a
|
2012-04-03T17:08:57
|
|
Unconstify xkb_rules_names
Since we never return an xkb_rules_names and it's all user-provided
strings, seems a bit harsh to have it const.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
69111405
|
2012-04-03T12:48:05
|
|
Properly document xkb_key_get_syms
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
034ffce6
|
2012-03-27T17:22:35
|
|
Use xkb_contexts in keymap compilation
Primarily for the include path, but also for the logging in future.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
3e9dd751
|
2012-03-27T16:59:01
|
|
Add new context API
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
b5efe41f
|
2012-03-24T04:48:31
|
|
Make build non-recursive
Unify all the different Makefile.am into a single short top level one
(the test/Makefile.am file is left intact though).
This makes the build system simpler to look and should encourage
unifying more currently-disparate code.
Some further motivation can be found in this page:
http://www.flameeyes.eu/autotools-mythbuster/automake/nonrecursive.html
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
602e8780
|
2012-03-24T13:27:48
|
|
Define our own NoSymbol value and use it
Since we have our own xkb_keysym_t type, it makes sense to have our own
NoSymbol value instead of the one from X11/X.h.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
d9f934ca
|
2012-03-23T16:52:23
|
|
Mention xkb_state_new can return NULL
in the header comments.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
087327d9
|
2012-03-27T14:41:44
|
|
Move doxygen comment before enum item
Signed-off-by: Guillem Jover <guillem@hadrons.org>
|
|
389c2db1
|
2012-03-27T13:44:48
|
|
Remove internal API from xkbcommon.h
And move it to XKBcomminint.h.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
3dcd7ae0
|
2012-03-27T12:20:42
|
|
Remove hardcoded legacy modifier masks
Use the xkb_state_mod_* and xkb_map_mod_* API instead.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
729ac12f
|
2012-03-27T12:19:42
|
|
Remove unused changes structs
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
f89b0a80
|
2012-03-27T12:18:50
|
|
Remove unused members of xkb_state
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
ede84734
|
2012-03-27T12:11:45
|
|
Add enum xkb_key_direction instead of bool
Use XKB_KEY_UP instead of 0 and XKB_KEY_DOWN instead of 1.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reported-by: Ran Benita <ran234@gmail.com>
|
|
7f471a70
|
2012-03-27T12:07:57
|
|
Add state serialisation API
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
d039622a
|
2012-03-22T17:39:12
|
|
Rename keymap allocation API
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
3d672fcf
|
2012-03-22T14:32:53
|
|
Add LED state API
And also convert state.c to use the state API for mods and groups,
rather than testing the state members directly.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
cfb07724
|
2012-03-22T14:30:58
|
|
Fix documentation bugs with mod/group state API
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|