Virtual mods augment not applied on previous explicit default definition

[wismill]

I expected the following:

xkb_keymap { 
    xkb_types { 
        virtual_modifiers M = 0;
        augment virtual_modifiers M = 1;
    };
};

to result in (simplified):

xkb_keymap {
    xkb_types {
        virtual_modifiers M = 1;
    };
};

but instead I got:

xkb_keymap {
    xkb_types {
        virtual_modifiers M;
    };
};

I do not think this is correct: setting M = 0 is equivalent to setting it to the default value of undefined mods, expect if overriding a previous definition¹. So the augment statement should take effect here.

Footnotes

1. e.g. M=1, then override M=0, resulting in M=0. ↩

[mahkoh]

setting M = 0 is equivalent to setting it to the default value of undefined mods

I'm not so sure about this. What should be the output of

        virtual_modifiers a = 1 - 1;
        augment virtual_modifiers a = Mod1;

[wismill]

First, given that virtual_modifiers a = 1 - 1; resolves to virtual_modifiers a = 0;, I expect both to have the same result.

Now, what result indeed? Currently setting virtual_modifiers a = 0 does not prevent a to be mapped via a key vmod + mod_map binding. So this definition is only resetting a vmod in the implicit mapping state, which augment can affect.

So:

    xkb_types { 
        virtual_modifiers M = 0; // *here*, equivalent to: virtual_modifiers M;
        augment virtual_modifiers M = 1;
        // Result: M = 1
    };

while:

    xkb_types { 
        virtual_modifiers M = 1

        // *not* equivalent to: virtual_modifiers M, because it overrides
        virtual_modifiers M = 0;
        // now we have: virtual_modifiers M;

        augment virtual_modifiers M = 2;
        // Result: M = 2
    };

Another approach would be to change current implementations to treat virtual_modifiers a = 0 as the other non-null explicit bindings and forbid any further mapping via key vmod + mod_map. But for now I do not see an appealing use case for this.

To sum up:

• Currently implementations interpret resulting explicit null mapping (virtual_modifiers a = 0 the same as implicit mapped (virtual_modifiers a). So I see no reason to not allow augment to be effective on such mappings.
• Should we decide to disallow augment to be effective, we should also disallow further mapping via key vmod + mod_map for consistency. But for what use case?!
• There are two incompatible features here: either virtual_modifiers a = 0 resets the mod into its implicit mapping state, or it disables any kind of mapping.

[wismill]

Relevant XKB protocol section:

XKB maintains a virtual modifier mapping , which lists the virtual modifiers associated with each key. The real modifiers bound to a virtual modifier always include all of the modifiers bound to any of the keys that specify that virtual modifier in their virtual modifier mapping.

I have not played with the X11 API to check if this mapping is indeed mandatory. But it suggests that virtual_modifiers a = 0; is a simple reset to implicit mapping, not an absolute setting. And that even non-null virtual_modifiers a = 1; is also not an absolute setting, but a mere initial state to be ORed by key definitions.

I find the case of non-null explicit mappings confusing though.

[mahkoh]

Now, what result indeed? Currently setting virtual_modifiers a = 0 does not prevent a to be mapped via a key vmod + mod_map binding.

I'm always allowing mods being implicitly added to a virtual modifier regardless of the declaration of the virtual modifier. Consider

// input
xkb_keymap {
    xkb_keycodes {
        <a> = 1;
    };
    xkb_types {
        virtual_modifiers a;
    };
    xkb_compat { };
    xkb_symbols {
        key <a> {
            [ X ],
            vmods = a
        };
        modmap Mod1 { <a> };
    };
};

The output is

        // output
        virtual_modifiers a = Mod1;

If we change the original map to

        // input
        virtual_modifiers a = 0;

then the output is still

        // output
        virtual_modifiers a = Mod1;

If we change the original map to

        // input
        virtual_modifiers a = 1;

then the output becomes

        // output
        virtual_modifiers a = Shift+Mod1;

That is, a virtual modifier is always in the implicit mapping state. That is, a virtual modifier can always be augmented by modmaps. I believe xkbcommon 1.8 behaves the same.

Currently implementations interpret resulting explicit null mapping (virtual_modifiers a = 0 the same as implicit mapped (virtual_modifiers a). So I see no reason to not allow augment to be effective on such mappings.

The reason would be consistency. For example, in both kbvm and xkbcommon 1.8, the output of

        // input
        indicator "X" {
            mods = 0;
            groups = all;
        };
        augment indicator "X" {
            mods = 1;
        };

is

        // output
        indicator "X" {
            mods = 0;
            groups = all;
        };

But the output of

        // input
        indicator "X" {
            // mods = 0;
            groups = all;
        };
        augment indicator "X" {
            mods = 1;
        };

is

        // output
        indicator "X" {
            mods = 1;
            groups = all;
        };

Why should virtual_modifiers a = 0 be treated differently than indicator.mods = 0?

There are two incompatible features here: either virtual_modifiers a = 0 resets the mod into its implicit mapping state, or it disables any kind of mapping.

I don't believe virtual_modifiers a = anything ever disables implicit mappings in any implementation.

[wismill]

I don't believe virtual_modifiers a = anything ever disables implicit mappings in any implementation.

You are right, I guess I got confused by:

• the explicit internal property and the implicit mapping via key vmods + modmap, that are in fact not mutually exclusive; and
• the fact that modmap None removes bindings, while virtual_modifiers M = none sets an explicit initial value and not unsets the mapping, as I thought before.

Explicit vmod values are quite new to me, because they do not seem to work at all on Xorg, do they?

Why should virtual_modifiers a = 0 be treated differently than indicator.mods = 0?

Good catch! It should not, indeed. We would need a special value or syntax (e.g. unset virtual_modifiers a;) in order to enable augment afterwards, but I see no point atm.

Thanks for helping decrypting