|
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>
|
|
4ac22263
|
2025-01-16T23:22:40
|
|
keysyms: Check clashes between keysyms names and keywords
Due to how our parser is implemented, keysyms names that are also valid
keywords require special handling.
Added a check for these clashes in the keysym generator. The only
current clash, `section`, is already handled. Note that it means that
e.g. `section`, `Section` and `sEcTiOn` all parse to the same keysym.
This side effect is fine here, because *currently* there is no other
keysym that clashes with any possible of the case variation of `section`.
But in order to be extra cautious, we now test thoses clashes too.
Hopefully we will never have a clash again, but while it is unlikely
that we modify the keywords, the keysyms are not a frozen set.
|
|
|
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.
|
|
|
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.
|
|
|
1a4a89a7
|
2023-09-28T09:50:43
|
|
Python: make ruff & black happy
|
|
|
68e69b7d
|
2021-03-28T20:22:54
|
|
keysym: use a perfect hash function for case sensitive xkb_keysym_from_name
In 7d84809fdccbb5898d0838849ec7c321410182d5 I added a fast path for the
case-sensitive case, but it is still slowing down Compose parsing.
Instead of the binary search, use a perfect hash function, computed with
a simple python module I found (vendored).
It is faster -- perf diff is:
Baseline Delta Abs Shared Object Symbol
........ ......... ................. ...................................
22.35% -14.04% libc-2.33.so [.] __strcmp_avx2
16.75% +10.28% bench-compose [.] xkb_keysym_from_name
20.72% +2.40% bench-compose [.] parse.constprop.0
2.29% -1.97% bench-compose [.] strcmp@plt
2.56% +1.81% bench-compose [.] resolve_name
2.37% +0.92% libc-2.33.so [.] __GI_____strtoull_l_internal
26.19% -0.63% bench-compose [.] lex
1.45% +0.56% libc-2.33.so [.] __memchr_avx2
1.13% -0.31% libc-2.33.so [.] __strcpy_avx2
Also reduces the binary size:
Before:
text data bss dec hex filename
341111 5064 8 346183 54847 build/libxkbcommon.so.0.0.0
After:
text data bss dec hex filename
330215 5064 8 335287 51db7 build/libxkbcommon.so.0.0.0
Note however that it's still larger than before 7d84809fdccbb5898d08388:
text data bss dec hex filename
320617 5168 8 325793 4f8a1 build/libxkbcommon.so.0.0.0
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
7d84809f
|
2021-03-28T15:51:01
|
|
keysym: fast path for case sensitive xkb_keysym_from_name
xkb_keysym_from_name() is called a lot in Compose file parsing. The
lower case handling slows things down a lot (particularly given we can't
use the optimized strcasecmp() due to locale issues). So add separate
handling for the non-case-sensitive case which is used by Compose.
To do this we need to add another version of the ks_tables table. This
adds ~20kb to the shared library binary. We can probably do something
better here but I think it's fine.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
670566f0
|
2019-12-27T15:03:10
|
|
Only add GCC diagnostic pragmas when compiler is GCC compatible
Avoid "unknown pragma" warnings on other compilers.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
0a19267f
|
2017-07-29T14:37:23
|
|
build: move custom targets to scripts/ and remove from makefile
These scripts generate source code that is committed to git and hence do
not really belong in the build system. A maintainer runs them as needed.
Signed-off-by: Ran Benita <ran234@gmail.com>
|