[thinkbud]

Ok, I admit that "not worth it" is better rephrased as "not the end goal". If the end goal is interactive gestures, one-off discrete gestures are welcome as an intermediate step or halfway solution.

Ideally the input framework would know if the streamed gesture was consumed real-time, and if not (e.g. no support for such interactice gesture in some program), the one-off event is issued.

This reminds me of current xorg libinput two finger scrolling / wheel event. Xinput2 is the relevant keyword but I am not sure exactly how it all fits in, only what I can observe: - applications that don't know about multi finger scroll/pan listen for and accept classic mouse4 / mouse5 events and interpret them to scroll in steps if relevant. As an example, xev x event testing uility is not xinput2 aware AFAIK nor are classic x or older gtk programs - applications can be xinput2-aware (e.g. eog Eye of Gnome image viewer, but maybe also any non-ancient gtk3 application as well), in which case they can scroll more directly (pixel-smooth) and with appropriate acceleration / smoothing / inertia (gtk-specific ?). In firefox there's an env var like MOZ_USE_XINPUT2 which tells firefox it can do this smoother wheel handling, not sure if it's required or automatic these days. To test received events including xinput2, there is utility xinput --test-xi2

As a closing anecdote, there's an interesting interaction bug I have experienced with xfce where both xfwm will react to Super+scroll (compositor-level full screen zoom), and the application under the mouse pointer will also react to the scroll up/down. I have not deciphered the interactions here but it depends on app under mouse cursor...