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>
Ran Benita
Peter Hutterer
Emmanuel Gil Peyrot
Jaroslaw Kubik
Jesse
Ran Benita
Hans de Goede
Mike Blumenkrantz