|
8f5270c0
|
2025-05-12T07:07:57
|
|
utils: Improve darray
- Introduce `darray_size_t`
- Document struct fields: the `alloc` field may be particularly confusing
|
|
df2322d7
|
2025-02-05T14:41:21
|
|
Replace include guards by `#pragma once`
We currently have a mix of include headers, pragma once and some
missing.
pragma once is not standard but is widely supported, and we already use
it with no issues, so I'd say it's not a problem.
Let's convert all headers to pragma once to avoid the annoying include
guards.
The public headers are *not* converted.
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>
|
|
|
502e9e5b
|
2025-01-29T12:19:10
|
|
xkbcomp: Add stricter bounds for keycodes and levels
Our current implementation uses continuous arrays indexed by keycodes
and levels. This is simple and good enough for realistic keymaps.
However, they are allowed to have big values that will lead to either
memory exhaustion or a waste of memory (sparse arrays).
Added the much stricter upper bounds `0xfff` for keycodes[^1] and 2048
for levels[^2], which should still be plenty enough and provides stronger
memory security.
[^1]: Current max keycode is 0x2ff in Linux.
[^2]: Should be big enough to satisfy automatically generated keymaps.
|
|
|
27ac30b2
|
2025-01-27T17:13:44
|
|
symbols: Normalize levels by dropping NoSymbol & NoAction
|
|
|
24fe4bac
|
2025-01-20T16:31:44
|
|
Fix undefined behaviours with NULL pointer
Issues detected by the sanitizers:
- fix indexing NULL pointer
- fix zero offset to NULL pointer
|
|
|
bf1ea088
|
2024-09-30T11:26:39
|
|
Fix typo in darray_enumerate_from
|
|
|
cdafba4f
|
2024-09-24T15:23:16
|
|
rules: Add support for index ranges
There is a lot of repetition in the current rules files provided by
xkeyboard-config, because the MLVO mappings need to match on the exact
layout/variant index. This also prevents to increase the number of
maximum groups, because it does not scale.
We introduces the following new special layout/variant indexes:
- “single”: matches a single layout; same as with no index.
- “first”: matches the first layout/variant, no matter how many layouts
are in the RMLVO configuration. It allows to merge `layout` and
`layout[1]` patterns.
- “later”: matches all but the first layout. This is an index range.
- “any”: matches layout at any position. This is an index range.
We also introduces the new `%i` expansion, which correspond to the index
of the matched layout in a mapping with an index range. Example:
layout[later] = symbols
my_layout = +my_symbols:%i
* = +%l[%i]:%i
Let’s have a look at concrete examples from xkeyboard-config:
! model layout = symbols
* * = pc+%l%(v)
! model layout[1] = symbols
* * = pc+%l[1]%(v[1])
! model layout[2] = symbols
* * = +%l[2]%(v[2])
! model layout[3] = symbols
* * = +%l[3]%(v[3])
! model layout[4] = symbols
* * = +%l[4]%(v[4])
! layout option = symbols
* grp:toggle = +group(toggle)
! layout[1] option = symbols
* grp:toggle = +group(toggle):1
! layout[2] option = symbols
* grp:toggle = +group(toggle):2
! layout[3] option = symbols
* grp:toggle = +group(toggle):3
! layout[4] option = symbols
* grp:toggle = +group(toggle):4
With this commit we can now simplify it into:
! model layout[first] = symbols
* * = pc+%l[%i]%(v[%i])
! model layout[later] = symbols
* * = +%l[%i]%(v[%i]):%i
! layout[any] option = symbols
* grp:toggle = +group(toggle):%i
The latter rule will work even if we increase XKB_MAX_GROUPS, whereas
the former would require to add the missing entries for the new groups.
In order to maintain consistent rules, we now disallow layout and
variant to have different indexes. For example, the following mapping
are now invalid:
- layout variant[1]
- layout[1] variant[2]
- layout[1] variant
- layout[first] variant[1]
- layout[first] variant
- layout variant[any]
- etc.
|
|
|
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>
|
|
afb26e7d
|
2020-05-12T14:09:50
|
|
Add libxkbregistry to query available RMLVO
This library is the replacement for clients parsing evdev.xml directly.
Instead, they should use the API here so that in the future we may even
be able to swap evdev.xml for a more suitable data format.
The library parses through evdev.xml (using libxml2) and - if requested -
through evdev.extras.xml as well. The merge approach is optimised for
the default case where we have a system-installed rules XML and another file in
$XDG_CONFIG_DIR that adds a few entries. We load the system file first, then
append any custom ones to that. It's not possible to overwrite the MLVO list
provided by the system files - if you want to do that, get the change upstream.
XML validation is handled through the DTD itself which means we only need to
check for a nonempty name, everything else the DTD validation should complain
about.
The logging system is effectively identical to xkbcommon.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
c9a499c9
|
2018-08-24T09:14:14
|
|
darray: fix unprotected macro argument
Reported-by: @msmeissn
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
4fcbc470
|
2017-06-26T21:49:49
|
|
darray: Don't call memcpy() on NULL
The only time we could ever hit this was with count == 0, which seems
unnecessarily pedantic. But OK.
Signed-off-by: Daniel Stone <daniels@collabora.com>
|
|
|
767fa86d
|
2017-12-21T14:18:07
|
|
Convert http:// -> https:// where possible
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
2963e29f
|
2017-12-12T14:43:24
|
|
xkbcomp/ast-build: fix memory leak when appending multi-keysyms
`syms` was not freed.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
e8b11232
|
2014-09-12T00:31:40
|
|
darray: add darray_shrink()
If we have a big array which can be finalized, on average we can give
back 1/4 of its size, which the allocator might be able to use.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
61fed8da
|
2014-07-26T00:19:34
|
|
Replace darray_mem with a new darray_steal
That's a more declarative interface.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
decb2915
|
2014-04-22T12:29:22
|
|
darray: remove unused darray_foreach_reverse()
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
d3d55f1c
|
2014-02-12T11:07:39
|
|
darray: fix indentation
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
b9b3593c
|
2014-02-08T01:13:50
|
|
darray: use unsigned int instead of size_t for array size
size_t is too large; if we ever need it, that's the least of our
problems. Besides, when we roll our own (e.g. in keymap.h) it's already
unsigned int. Instead, add some emergency overflow check. So, why?
- It plays nicer with all the other uint32_t's and unsigned int's (no
extensions, etc.).
- Reduces keymap memory usage by 5% or so as a bonus.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
fa87cdb8
|
2014-02-07T19:39:42
|
|
darray: cleanup
We have quite diverged from the upstream file, so let's make it at least
easier to look at. Remove some unused macros and rename some for
consistency.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
a7b1f80d
|
2013-03-02T20:43:57
|
|
Build cleanly with clang
clang doesn't like the use of typeof with out default flags, so just
don't use it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
428c6f31
|
2012-09-22T02:05:48
|
|
symbols: convert KeyInfo->groups to darray
Before it was a static array of size XKB_NUM_GROUPS.
The previous cleanups made this transition a bit easier. This is a
first step for removing the XKB_NUM_GROUPS hardcoded limit; but for now
we still check that the groups are < XKB_NUM_GROUPS (e.g. in
ResolveGroup and GetGroupIndex) until the keymap, etc. is worked out as
well.
This also makes us alloc quite a bit less (this is just rulescomp):
Before:
==51999== total heap usage: 291,474 allocs, 291,474 frees, 21,458,334 bytes allocated
After:
==31394== total heap usage: 293,595 allocs, 293,595 frees, 18,150,110 bytes allocated
This is because most rmlvo's don't use the full 4 layouts that KeyInfo
had always alloced statically before.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
18048cb7
|
2012-08-02T17:59:57
|
|
darray: fix formatting
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
d0097f4e
|
2012-07-15T15:55:34
|
|
Pass around xkb_key's instead of keycodes
This way we don't need to look up the key every time. We now only deal
with keycodes in the public API and in keycodes.c.
Also adds an xkb_foreach_key macro, which is used a lot.
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>
|
|
|
bc50cdd4
|
2012-06-05T18:46:24
|
|
darray: some changes for convenience
- Make darray_free also initialize the array back to an empty state, and
stop worrying about it everywhere.
- Add darray_mem, to access the underlying memory, which we do manually
now using &darray_item(arr, 0). This makes a bit more clear when we
actually mean to take the address of a specific item.
- Add darray_copy, to make a deep copy of a darray.
- Add darray_same, to test whether two darrays have the same underlying
memory (e.g. if the struct itself was value copied). This should used
where previously two arrays were compared for pointer equality.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
57f184e2
|
2012-05-30T15:55:21
|
|
darray: tweak parameters a bit for better memory usage
Here are some quick numbers from valgrind, running rulescomp only with a
simple, common "us,de" rule set:
before darray: cb047bb
total heap usage: 44,924 allocs, 44,924 frees, 3,162,342 bytes allocated
after darray: c87468e
total heap usage: 52,670 allocs, 52,670 frees, 2,844,517 bytes allocated
tweaking specific inital allocation sizes:
total heap usage: 52,652 allocs, 52,652 frees, 2,841,814 bytes allocated
changing initial alloc = 2 globally
total heap usage: 47,802 allocs, 47,802 frees, 2,833,614 bytes allocated
changing initial alloc = 3 globally
total heap usage: 47,346 allocs, 47,346 frees, 3,307,110 bytes allocated
changing initial alloc = 4 globally
total heap usage: 44,643 allocs, 44,643 frees, 2,853,646 bytes allocated
[ Changing the geometric progression constant from 2 only made things
worse. I tried the golden ratio - not so golden :) ]
The last one is obviously the best, so it was chosen, with the specific
tweaks thrown in as well (these were there before but don't make much
difference). Overall it seems to do better than the previous manual
allocations which is a bit surprising.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
c65a3596
|
2012-05-22T10:59:46
|
|
keytypes: use darray for xkb_kt_map_entry's
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
c815ff96
|
2012-05-21T23:33:56
|
|
Import darray.h for common dynamic array code
Signed-off-by: Ran Benita <ran234@gmail.com>
|