How to handle new features?

[wismill]

The current approach to add new features is to create a new keymap format version v2 in #754.

The idea behind keymap format v2 is to add features that are “really” incompatible with X11, such as:

1. Raise layout limit to 32 (Raise the layout limit to 32 #515)
2. Use pure virtual modifiers¹ (state: support pure virtual modifiers V2 #757, Experiment: state: support pure virtual modifiers #450)
3. Add new action options that break the XKB protocol (Actions/locks xkb extension v3 #527)
4. (More?)

However, we already added new features without using a new format:

• Multiple actions per level
• Keysyms as strings
• Void()
• (more ?)

The last 2 are not really breaking, because we do not use them when serializing. As for the first, I would like to make xkbcomp ignore multiple actions per level the same way it ignores multiple keysyms per level at some point, for consistency.

So I wonder if it is really necessary to introduce a new format:

• Wayland has currently no mechanism to handle keymap version negotiation.
• Since most of the new features matters only to compositors, an option (on by default) to serialize to backward-compatible keymaps may be enough?

Note that kbvm has fine-grained options to serialize for XWayland, but it may not scale if we continue to add features.

cc @whot @bluetech @mahkoh

Footnotes

1. I am thinking to introduce the self special value to use more “explicit” mapping, e.g. virtual_modifiers M = self;, rather mapping auto-magically any unmapped modifier. ↩