Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect handling of unbound virtual modifiers in key types #578

Open
mahkoh opened this issue Jan 5, 2025 · 1 comment · May be fixed by #450
Open

Incorrect handling of unbound virtual modifiers in key types #578

mahkoh opened this issue Jan 5, 2025 · 1 comment · May be fixed by #450
Labels
bug Indicates an unexpected problem or unintended behavior state Indicates a need for improvements or additions to the xkb_state API

Comments

@mahkoh
Copy link

mahkoh commented Jan 5, 2025

Consider the following map:

xkb_keymap {
    xkb_keycodes {
        <a> = 38;
        <leftshift> = 50;
    };
    xkb_types {
        virtual_modifiers Bound = Shift, Unbound;

        type "X" {
            modifiers = Bound+Unbound;
            map[Bound+Unbound] = Level1;
            map[Bound] = Level2;
        };
    };
    xkb_compat { };
    xkb_symbols {
        key <a> {
            type = "X",
            [ a, A ]
        };
        key <leftshift> {
            [ SetMods(mods = Shift) ]
        };
    };
};

The specification requires that

Map entries which specify unbound virtual modifiers (see Inactive Modifier Definitions) are not considered
[...]
When it is essential to distinguish between OneThing and Another, XKB considers only those modifier definitions for which all virtual modifiers are bound.

Since Unbound is not bound, the line

            map[Bound+Unbound] = Level1;

should be ignored.

But xkbcommon does not ignore it and maps Shift+a to Level1.

@wismill
Copy link
Member

wismill commented Jan 7, 2025

Good catch! Although with #450 landing soon, this will work as expected. So we should just wait for #450 to fix it.

@wismill wismill added bug Indicates an unexpected problem or unintended behavior state Indicates a need for improvements or additions to the xkb_state API labels Jan 7, 2025
@wismill wismill linked a pull request Jan 7, 2025 that will close this issue
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior state Indicates a need for improvements or additions to the xkb_state API
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants