Edit

kc3-lang/libxkbcommon/changes

Branch :

  • Show log

    Commit

  • Author : Pierre Le Marre
    Date : 2025-10-17 11:57:53
    Hash : 939bf0e1
    Message : xkbcomp: Never drop X11 canonical key types There are 4 mandatory *canonical key types* in the XKB protocol: - `ONE_LEVEL` - `TWO_LEVEL` - `ALPHABETIC` - `KEYPAD` They are always present in the keymap generated from xkeyboard-config. But since 31900860c65b88e4d10ad7dd00377e2815cca0f6 we drop unused key types by default, which may happen for the types hereinabove with e.g. 4+ level layouts like `es`. In theory these types are automatically filled by libX11 if missing, but there are some bugs in the X11 ecosystem that prevents the keymap to be properly uploaded in the X server, leading to errors when retrieving it with libxkbcommon-x11. See: https://gitlab.archlinux.org/archlinux/packaging/packages/libxkbcommon/-/issues/3 The following fixes were filed to fix the issues: - https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/292 - https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2082 - https://github.com/xkbcommon/libxkbcommon/pull/871 However it’s not clear when new versions of libX11 and xserver will be released. So this commit is a hack to ensure that we do not drop the XKB canonical key types, as an effort to reduce breakage. WARNING: contrary to `xkbcomp`, we do not supply these types if they are missing, because a keymap that uses them (explicitly `type="…"` or implicitly with automatic types) without providing them is considered buggy. The only exception is if no key type is provided, a default one- level type `ONE_LEVEL` is provided and assigned to all keys.

  • README.md

  • Fragments for the changelog

    This directory contains fragments for the future NEWS file.

    Introduction

    We use towncrier to produce useful, summarized news files.

    There are 3 sections types:

    • API: changes/api
    • Tools: changes/tools
    • Build System: changes/build

    There are 4 news fragments types:

    • Breaking changes: .breaking
    • Deprecated: .deprecated
    • New: .feature
    • Fixes: .bugfix

    Adding a fragment

    Add a short description of the change in a file changes/SECTION/ID.FRAGMENT.md, where:

    • SECTION and FRAGMENT values are described in the previous section.
    • ID is the corresponding issue identifier on Github, if relevant. If there is no such issue, then ID should start with + and some identifier that make the file unique in the directory.

    Examples:

    • A bug fix for the issue #463 is an API change, so the corresponding file should be named changes/api/463.bugfix.md.
    • A new feature for tools like #448 corresponds to e.g. changes/tools/+add-verbose-opt.feature.md.

    Guidelines for the fragment files:

    • Use the Markdown markup.
    • Use past tense, e.g. “Fixed a segfault”.
    • Look at the previous releases NEWS file for further examples.

    Build the changelog

    Install towncrier from Pypi:

    python3 -m pip install towncrier

    Then build the changelog:

    # Only check the result. Useful after adding a new fragment.
towncrier build --draft --version 1.8.0
# Write the changelog & delete the news fragments
towncrier build --yes --version 1.8.0