|
4b6fc7d8
|
2025-09-02T09:49:54
|
|
doc: Improve User-configuration
|
|
|
27ba56ae
|
2025-05-07T10:55:24
|
|
doc: Add initial documention for XKB_KEYMAP_FORMAT_TEXT_V2
|
|
|
58397e94
|
2025-05-06T18:05:30
|
|
Deprecate xkb_keymap_new_from_names()
- Deprecate `xkb_keymap_new_from_names()` in favor of
`xkb_keymap_new_from_names2()`
- Add new changelog fragment type `deprecated`.
- Change documentation to use the new function.
|
|
|
9b0b8c68
|
2025-04-15T19:53:28
|
|
xkbcomp: Stricter handling of default map include
Before this commit, including a *default* map, i.e. without an explicit
section name (e.g. `include "au"` vs `include "au(basic)"`) would match
the first section of the first matching file in the XKB include paths,
even if this section is not an *explicit* default map (i.e. tagged with
`default`) but an *implicit* default map (i.e. the first map of the
file, i.e. a weak match).
It makes user configuration risky: say a user wants to create a custom
version `au(custom)` of the `au` layout:
- `./config/xkb/symbols/au`: custom layout in section “custom”.
- `/usr/share/X11/xkb/symbols/au`: system layout, with *default* section
“basic”.
In this setup *any* layout that imports the default map from `au` would
in fact import the *implicit* default map `au(custom)` instead of the
*explicit* default map `au(basic)`.
This incorrect behavior may thus break setups with multiple layouts.
This is especially true for symbols files such as: `pc`, `us` or `latin`.
Fixed by trying harder to found the exact default map, defaulting to the
old behavior (weak match) only if no *explicit* default map (exact match)
has been found in the XKB include paths.
|
|
|
04220319
|
2025-03-08T17:57:56
|
|
doc: Warn about the options order
Options are always applied depending of their order in the relevant
rules files, independently of their order in the relevant RMLVO config.
Since this is counter-intuitive (e.g. when using `xkbcli`), let’s
highlight this in the documentation.
|
|
|
d2eb8601
|
2025-01-07T08:00:06
|
|
doc: Mark $HOME/.xkb/ as a deprecated location for user configuration
`$HOME/.xkb` was supported before the addition of the XDG directories.
Removal of the functionality is just going to cause potential breakage
for now good technical reason.
See https://specifications.freedesktop.org/basedir-spec/latest/ for
further details.
|
|
|
16eff222
|
2024-12-31T08:01:52
|
|
doc: Add debugging page and warning about session restart
Co-authored-by: Pierre Le Marre <dev@wismill.eu>
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
2c23852a
|
2024-02-29T18:16:54
|
|
Doc: Keymap format enhancement + misc
- Add introduction to keymap and its components
- Add a diagram to explain the relationships between RMLVO and KcCGST.
- Add keywords & comments sections.
- Improve Quick guide section in the index page.
- Add links to User-configuration page.
- Fix typos.
|
|
|
79502700
|
2023-11-14T10:10:50
|
|
Doc: fix malformed links and some typos
|
|
8b603dbe
|
2021-04-10T23:28:06
|
|
doc: fix user-configuration sample file
Support copy-pasting from the docs to get something functional.
Signed-off-by: Jouke Witteveen <j.witteveen@gmail.com>
|
|
ae90a6a0
|
2020-08-26T15:47:51
|
|
doc: add some disclaimer regarding user-specific key types and compat entries
It's a niche use-case but basically the same as adding symbols, so let's go with
a general handwavy explanation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
d7b39f6f
|
2020-07-10T08:50:02
|
|
Add /etc/xkb as extra lookup path for system data files
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>
|
|
|
afb26e7d
|
2020-05-12T14:09:50
|
|
Add libxkbregistry to query available RMLVO
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>
|
|
|
4e544e27
|
2020-06-16T10:44:48
|
|
doc: correct the include path list
XKB_CONFIG_ROOT (if defined) replaces the built-in system directories.
Fixes 5fb2c6769b7259ba647781bc800d6a46d90cf1a9
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
5fb2c676
|
2020-06-02T16:18:47
|
|
doc: add documentation for user configuration
Most of this is currently hidden in the commit message for ca033a29d2ca, let's
make it a bit more public so we have a link to point users to.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|