The majority use-case for extending XKB on a machine is to override one or a
few keys with custom keycodes, not to define whole layouts.
Previously, we relied on the rules file to be a single file, making it hard to
extend. libxkbcommon parses $XDG_CONFIG_HOME/xkb/ but that only works as long
as there is a rule that matches the user-specified RMLVO. This works for MLV
but not for options which don't have a wildcard defined. Users have to copy
the whole rules file and then work from there - not something easy to extend
and maintain.
This patch adds a new ! include directive to rules files that allows including
another file. The file path must be without quotes and may not start with the
literal "include". Two directives are supported, %H to $HOME and %S for the
system-installed rules directory (usually /usr/share/X11/xkb/rules).
A user would typically use a custom rules file like this:
! option = symbols
custom:foo = +custom(foo)
custom:bar = +custom(baz)
! include %S/evdev
Where the above defines the two options and then includes the system-installed
evdev rule. Since most current implementations default to loading the "evdev"
ruleset, it's best to name this $XDG_CONFIG_HOME/xkb/rules/evdev, but any
valid name is allowed.
The include functionally replaces the line with the content of the included
file which means the behavior of rules files is maintained. Specifically,
custom options must be defined before including another file because the first
match usually wins. In other words, the following ruleset will not assign
my_model as one would expect:
! include %S/evdev
! model = symbols
my_model = +custom(foo)
The default evdev ruleset has wildcards for model and those match before the
my_model is hit.
The actual resolved components need only be in one of the XKB lookup
directories, e.g. for the example above:
$ cat $XDG_CONFIG_HOME/xkb/symbols/custom
partial alphanumeric_keys
xkb_symbols "foo" {
key <TLDE> { [ VoidSymbol ] };
};
partial alphanumeric_keys
xkb_symbols "baz" {
key <AB01> { [ k, K ] };
};
This can then be loaded with the XKB option "custom:foo,custom:bar".
The use of "custom" is just as an example, there are no naming requirements
beyond avoiding already-used ones. Also note the bar/baz above - the option
names don't have to match the component names.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This requires (well, at least implemented by) casting away `const` which
is undefined behavior, and clang started to warn about it.
The micro optimization didn't save too many allocations, anyway.
Signed-off-by: Ran Benita <ran@unusedvar.com>
A few lines above we check path_rel[0], so any null pointer will blow up
before we get here.
Found by coverity
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
python3 is always python3, but python could be python2 in some cases. Or just
missing (e.g. RHEL8).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This way stdin/stdout of the process are opened in text mode and we don't need
manually decode.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In python multiprocessing, each process needs to handle (and ignore) the
KeyboardInterrupt to avoid exception logging. This is a separate patch for
easier reviewing, the first hunks merely re-indent all of the
xkbcommontool/xkbcomp functions into a try/except KeyboardInterrupt block.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a change in behavior and requires any automated callers to adjust
accordingly. Still, much easier to get the errors that way rather than it
being mixed into a thousands-of-lines output file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Collect all options into a dictionary, then process that as async actions
through a process pool. This of course requires collecting the various print
statements to avoid mangled output.
This dropped the time to completion from around 14 min to 8 min on my local
machine (unscientific single run only for the original timing).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All tests create a temporary directory, set up the environment for that
directory and then check the include paths for the presence of that directory,
ideally in the right position of the list.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
xkbcomp only accepts the "Level" prefix for a level name for levels 1 to
8, but the keymap dumping code added it always, e.g. "Level15".
The plain integer, e.g. "8", "15" is always accepted, so just use that.
Fixes https://github.com/xkbcommon/libxkbcommon/issues/113
Signed-off-by: Ran Benita <ran@unusedvar.com>
Reported-by: progandy
xdg_shell v6 was pretty close to the finalised stable version of
xdg-shell. We can now just use the stable version, which is supported
everywhere (Enlightenment, KWin, Mutter, Weston, wlroots).
This requires bumping the wayland-protocols dependency.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This test contains of two parts:
- a simple program to convert RMLVO commandline arguments into a keymap (and
print that keymap if requested).
- a python script that runs through rules/evdev.xml, and tries to compile a
keymap for sort-of every layout/variant/option combination. Sort-of, because
we can have multiple options and it really only does one per layout(variant)
combination.
Same thing can be done using xkbcomp, but right now it doesn't take that as
argument, it's hard-coded.
This takes quite a while, installing python-tqdm is recommended to see fancy
progress bars instead of just miles of dumps.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Can happen in cases like:
- There was an error between the error check and the call.
- The internal poll() fails.
Signed-off-by: Ran Benita <ran234@gmail.com>
The enum seems large, and we don't handle all of the values in it.
Previously if we got an unrecognized SHM format we would use an
uninitialized `stride`.
Signed-off-by: Ran Benita <ran234@gmail.com>
Mutter only implements v6 now, and Weston also implements that. Port
interactive-wayland to this so people can keep on using it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
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>
The current functions dealing with consumed modifiers use the
traditional XKB definition of consumed modifiers (see description in the
added documentation). However, for several users of the library (e.g.
GTK) this definition is unsuitable or too eager. This is exacerbated by
some less-than-ideal xkeyboard-config type definitions (CTRL+ALT seems
to cause most grief...).
So, because we
- want to enable alternative interpretations, but
- don't want to expose too much internal details, and
- want to keep things simple for all library users,
we add a high-level "mode" parameter which selects the desired
interpretation. New ones can be added as long as they make some sense.
All of the old consumed-modifiers functions keep using the traditional
("XKB") mode. I mark xkb_state_mod_mask_remove_consumed() and as
deprecated without adding a *2 variant because I don't it is very useful
(or used) in practice.
Alternative modes are added in subsequent commits (this commit only adds
a mode for the existing behavior).
https://github.com/xkbcommon/libxkbcommon/issues/17
Signed-off-by: Ran Benita <ran234@gmail.com>
Peter Hutterer
Ran Benita
Ran Benita
worldofpeace
Daniel Stone
Naman Dixit