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>
Needed for some tests. The tests need some adjustment, mostly because of
the resolution of xkeyboard-config bug
https://bugs.freedesktop.org/show_bug.cgi?id=50935
Also add the 'ch' symbols file for future tests.
Signed-off-by: Ran Benita <ran234@gmail.com>
Sync the files again from xkeyboard-config 2.8, since there have been
some changes we should test against.
Also added a script test/data/sync.sh if we want to do it again in the
future.
Signed-off-by: Ran Benita <ran234@gmail.com>
This is a proof-of-concept for the long key names. The keycodes in the
file evdev-xkbcommon are autogenerated from linux/input.h, and uses the
names given there; all of the previous names are aliased to the new
names, so they continue to work with the symbols files, etc.
You can try it with 'sudo ./test/interactive -r evdev-xkbcommon -n 0'
The -n 0 means that we don't offset the evdev scan codes - just feed
them directly. The -r evdev-xkbcommon just means to use a new rules file
which makes us use the new keycodes file. (The only problem I can see is
with the MENU and LSGT names which has some conflicts).
Maybe some day xkeyboard-config could ship something similar, so that
the 8 offset is unneeded.
Signed-off-by: Ran Benita <ran234@gmail.com>
There are two ways to separate multiple files in XKB include statements:
'+' will cause the later file to override the first in case of conflict,
while '|' will cause it augment it (this is done by xkbcomp). '!' is
unrelated here.
Since '|' is practically never used, this wasn't noticed.
In the modified test, the '|some_compat' previously was just ignored.
Signed-off-by: Ran Benita <ran234@gmail.com>
Since we now handle empty model/layout, the last couple of tests should
not fail. The reason they do is bacause they try to use a non-existent
"base" rules file. When the file is brought in these tests do not fail.
Since we already test for non-existent rules file, we can remove them,
and refine the other tests a bit.
Signed-off-by: Ran Benita <ran234@gmail.com>
Use a self-contained dataset instead of relying on a globally-installed
set. Data taken from xkeyboard-config 2.5.1.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This was broken by commit 18d331b86b
(where only the first option out of a comma-separated string was
matched). Do it correctly this time and add a test.
Signed-off-by: Ran Benita <ran234@gmail.com>
Add a non-extensive test to check that some basic things (e.g. rule
matching, var substitution, indexes and groups) work as expected.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Peter Hutterer
Ran Benita
Daniel Stone