Protocol requirements for multiple input mappers

[kermitfrog]

Let's collect what we need for multiple mappers to work together in this post. Feel free to edit (I don't think I can make it editable for others, so I'll just collect everything in this post (starting in a few days))

We need a way to..

• generate new events and block existing events;
• feed the events from one mapper into another mapper, for example to make a foot switch able to function as a ctrl button;
• deterministically set the order in which one mapper feeds into the other, we don't want that randomized every reboot;
• add and remove programs to the input-mapping chain and have them interact with each other in the specified order even if they were started in a different order, lest a reboot is needed every time the user experiments with a configuration change;
• inject some events into the chain from a short-lived script without significant delay, lest xdotool needs to keep a daemon running to be able to occasionally send keys;
• identify which device has triggered a specific event. (Putting it here so we don't forget the current limitations of libinput seats)

Not strictly necessary for working together, but nice-to-haves:

• Some way to map to unicode symbols that are not on the current keyboard layout;
• Some way to map to unicode grapheme clusters;
• Some way to change the mappings based on the active window.
• A way to deal with changes in the input chain like configuration change or insert | remove of mapper that happen mid-event.

[KarsMulder]

From the top of my head, we need:

• Some way to generate new events and block existing events;
• Some way to feed the events from one mapper into another mapper, for example to make a foot switch able to function as a ctrl button;
• Some way to deterministically set the order in which one mapper feeds into the other, we don't want that randomized every reboot;
• Some way to add and remove programs to the input-mapping chain and have them interact with each other in the specified order even if they were started in a different order, lest a reboot is needed every time the user experiments with a configuration change;
• Some way to inject some events into the chain from a short-lived script without significant delay, lest xdotool needs to keep a daemon running to be able to occasionally send keys;

Not strictly necessary for working together, but nice-to-haves:

• Some way to map to unicode symbols that are not on the current keyboard layout;
• Some way to map to unicode grapheme clusters;
• Some way to change the mappings based on the active window.

Possible interference to think about:

• Suppose there is a macro that would type "Hello world!" when a certain button is pressed. If the user holds the shift key, do we want that string to turn into "HELLO< WORLD!"? If the user does not hold the shift key and tries to type "a" while the macro tries to type "H", would it be acceptable that "AHello" or "HAello" gets typed because the "shift+h" also ended up affecting the "a" key?
• Suppose the user is holding the "o" key while the above macro is running. The macro will try to send "o down, o up" events. How does this interact? Does the first "o down" get skipped because it was already down? After the second "o", does the "o" key end in the KEY_UP state even if the user is still holding it down physically?

(I'm saying "user" here, but that user could of course very well be a second script interfering with the first script. Unfortunately the current Wayland input protocol exposes only a single keyboard per seat.)