This completes the usual triplet of configuration locations available for most
processes:
- vendor-provided data files in /usr/share/X11/xkb
- system-specific data files in /etc/xkb
- user-specific data files in $XDG_CONFIG_HOME/xkb
The default lookup order user, system, vendor, just like everything else that
uses these conventions.
For include directives in rules files, the '%E' resolves to that path.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Before reading ~/.XCompose, try to read $XDG_CONFIG_HOME/XCompose
(falling back to ~/.config/XCompose).
This helps unclutter the home directory of users who want that.
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>
The new API is useful to implement features like auto-type and
desktop automation. Since the inputs for these features is usually
specified in terms of the symbols that need to be typed, the
implementation needs to be able to invert the keycode->keysym
transformation and produce a sequence of keycodes that can be used
to type the requested character(s).
In order to support features like auto-type and UI automation, the
relevant tools need to be able to invert the keycode->keysym->text
transformation. In order to facilitate that, a new API was added.
It allows querying the keysyms that correspond to particular Unicode
codepoints. For all practical purposes, it can be thought of as an
inverse of xkb_keysym_to_utf32().
xproto recently has been extended with 2 new keysyms:
XF86XK_MonBrightnessCycle
XF86XK_RotationLockToggle
This commit is the result of running "scripts/update-keysyms" on a system
with the updated xproto installed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
These can be useful in some odd cases.
There is already an implementation (+ tests) for internal use, so all
that's needed is to export them.
If xkbcommon were to provide a way to convert a Unicode codepoint to a
keysym, this could have been implemented externally as follows:
uint32_t codepoint = xkb_keysym_to_utf32(keysym);
uint32_t upper_codepoint = my_unicode_library_to_upper(codepoint);
xkb_keysym_t upper_keysym = theoretical_xkb_keysym_from_utf32(upper_codepoint);
However keysym -> codepoint is not injective so such a function is not
possible strictly speaking.
Signed-off-by: Ran Benita <ran234@gmail.com>
The previous code would cause failures to find the Compose file if one
of the environment variables LC_ALL, LC_CTYPE or LANG are set to the
empty string.
The description of the fallback procedure in loclale(7) talks about
"non-null environment variable"; I interpreted this to mean the
environment variable is unset, but it actually means unset or empty (I
verified this by looking at what glibc and musl do).
A recent bug in systemd https://github.com/systemd/systemd/issues/6407
exposed this issue. It causes these these variables to be set to the
empty string in TTY sessions.
Reported by "doodoo" in https://bbs.archlinux.org/viewtopic.php?id=228658
Signed-off-by: Ran Benita <ran234@gmail.com>
A bit more manageable this way, and the other part of the target is
already using python.
The output is the same, except I removed the reference to Makefile.am.
Signed-off-by: Ran Benita <ran234@gmail.com>
xproto recently has been extended with 4 new keysyms:
XF86XK_Keyboard
XF86XK_WWAN
XF86XK_RFKill
XF86XK_AudioPreset
This commit is the result of running "make update-keysyms" on a system
with the updated xproto installed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
See the NOTES section of getenv(3). Somewhat obscure but it doesn't hurt
to reassure the readers who know about this.
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>
xkb_keymap_key_by_name() allows finding a keycode from a given keyname and
is useful for generating keyboard events to use in regression tests
during CI
xkb_keymap_key_get_name() is the inverse of xkb_keymap_key_by_name()
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
[ran: some stylistic tweaks + another test case]
Signed-off-by: Ran Benita <ran234@gmail.com>
xkbcommon-compose is a Compose implementation for xkbcommon. It mostly
behaves like libX11's Compose, but the support is somewhat low-level and
is not transparent like in libX11. The user must add some supporting code
in order to utilize it.
The intended audience are users who use xkbcommon but not a full-blown
input method. With this they can add Compose support in a straightforward
manner, so they have a fairly complete keyboard input for Latin-like
languages at least.
See the header documentation for details.
Signed-off-by: Ran Benita <ran234@gmail.com>
The @level argument is restricted by xkb_keymap_num_levels_for_key(). Fix
the description to no longer mention xkb_keymap_num_layouts_for_key().
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
The documentation should be clear about what is happening, even if it's
rather unlikely anyone will really dig into the details.
Signed-off-by: Ran Benita <ran234@gmail.com>
And also add release dates to the NEWS.
We're adding API freely, so this can make life easier for anyone who
wants to stay compatible with an older version.
Signed-off-by: Ran Benita <ran234@gmail.com>
These functions generally have the same effect as
xkb_state_key_get_syms() + xkb_keysym_to_utf{8,32}().
So why add them?
- They provide a slightly nicer interface, especially if the string is
the only interest.
- It makes the handling of multiple-keysyms-to-utf8 transparent. For the
designated use-case of multiple-keysyms (unicode combining
characters), this is a must. We also validate the UTF-8, which the
user might not otherwise do.
- We will need to apply some transformation on the resulting string
which depend on the xkb_state. This is not possible with the
xkb_keysym_* functions.
With these functions, the existing xkb_keysym_to_utf{8,32}() are not
expected to be used by a typical user; they are "raw" functions.
Signed-off-by: Ran Benita <ran234@gmail.com>
Peter Hutterer
Emmanuel Gil Peyrot
Ran Benita
Jaroslaw Kubik
Jesse
Ran Benita
Hans de Goede
Mike Blumenkrantz
David Herrmann