Support querying whether virtual modifiers are active (alternative 2)

[wismill]

Allow to query also virtual modifiers with the following functions, so they work with any modifiers (real and virtual):

• xkb_state_mod_index_is_active
• xkb_state_mod_indices_are_active
• xkb_state_mod_name_is_active
• xkb_state_mod_names_are_active
• xkb_state_mod_index_is_consumed
• xkb_state_mod_index_is_consumed2

Warning: they may overmatch in case there are overlappings virtual-to-real
modifiers mappings.

Also added the following modifiers names definitions in xkbcommon-names.h:

• XKB_MOD_NAME_MOD1
• XKB_MOD_NAME_MOD2
• XKB_MOD_NAME_MOD3
• XKB_MOD_NAME_MOD4
• XKB_MOD_NAME_MOD5
• XKB_VMOD_NAME_ALT
• XKB_VMOD_NAME_META
• XKB_VMOD_NAME_NUM
• XKB_VMOD_NAME_SUPER
• XKB_VMOD_NAME_HYPER
• XKB_VMOD_NAME_LEVEL3
• XKB_VMOD_NAME_LEVEL5
• XKB_VMOD_NAME_SCROLL

---

This is a simplier version of #353, which is also an alternative to #36.

This is necessary to implement fully #450.

Fixes #88

[wismill]

TODO: more tests, with all modifiers. We want this to be 100% reliable, with no breaking changes in the known and foreseen uses.

[wismill]

We should probably deprecate the following in favor of the new names:

• XKB_MOD_NAME_ALT → XKB_VMOD_NAME_ALT
• XKB_MOD_NAME_LOGO → XKB_VMOD_NAME_SUPER
• XKB_MOD_NAME_NUM → XKB_VMOD_NAME_NUM

[whot]

I think this LGTM though admittedly I haven't managed to page everything back in in detail. Two nitpicks, otherwise 👍

[wismill]

Added support for xkb_state_mod_mask_remove_consumed as well. I am going reactivate the draft status, as this latter function failure was not caught by the test. Well, the function is deprecated, but it is also still supported!

[wismill]

I do not see other functions requiring changes.

[bluetech]

It will be very cool if we can make this work.

I only did a very shallow skim of the code. I too have mostly forgotten the details unfortunately. Some questions:

1. Is the overmatching possibility fundamental to the way virtual modifiers work, or is it possible to rework the internals such that they track particular vmods?

2. Does this work for xkbcommon-x11?

3. In practice, I think most users ignore the is_active functions and just use xkb_state_serialize_mods, despite it being documented as for serialization only. Unfortunate, and maybe it has changed by now, but probably not, since people always take the path of least resistance. The question is -- is there anything we can do about it?

[wismill]

Some questions:

1. Is the overmatching possibility fundamental to the way virtual modifiers work, or is it possible to rework the internals such that they track particular vmods?

@bluetech Unfortunately it’s fundamental, at least until #450 is merged. Here some examples:

1. Alt and Meta both map to Mod1 by default, so activating any of the 3 modifiers activates the two others.
2. If a virtual modifier is mapped to 2 real modifiers, activating these 2 modifiers independently will also activate this vmod.

In practice, 1) is already an issue so DE and apps handle it already. 2) is probably extremely rare and more due to an accident. The only use I know is to differentiate left and right variant of a modifier.

2. Does this work for xkbcommon-x11?

Yes, AFAICT: in the end we rely on the real modifiers. It will start to change when #450 is merged.

3. In practice, I think most users ignore the is_active functions and just use xkb_state_serialize_mods, despite it being documented as for serialization only. Unfortunate, and maybe it has changed by now, but probably not, since people always take the path of least resistance. The question is -- is there anything we can do about it?

That is a good question! State and its value are supposed to be opaque, as stated by Daniel in this Wayland issue. This may change, but apps working on states values directly expose themselves to bugs. Do you have some examples in mind?

More probably they replicate the logic, like KDE KWin. Anyway, if they work directly with the state mod masks they must already work with real modifiers and I did not change the state representation/serialization with the current MR. Again, what is a real modifier will change when #450 get merged: we will have to distinguish X11 and non-X11 real modifiers, because “pure” virtual modifiers as stated in #450 are in fact non-X11 real modifiers.

So, until this Wayland issue declare the contrary, the only thing we can do about it is to document that the state values should only be processed by the xkbcommon API.

[wismill]

Updated according to @bluetech review.