Example: If you where scrolling in a window, the driver kept sending scroll events for a short time to simulate kinetic scrolling. Now, if you moved the cursor to another window, the other window started scrolling, because of the simulated events.
This is not the case on macOS. Changing window focus doesn't change the scrolling. So, while working from a user perspective (in my opionion this would have been better, than NO kinetic scrolling at all), technically, it is a bug / unsolvable behaviour :-), because this problem cannot be solved on the driver level - there is no reference to the current focussed "window" / active element.
That's probably the reason why they thought: This must be solved at App level, which was the worst decision they could make. Putting the effort on the shoulders of App developers instead of solving it at one place leads to so much wasted developer time, that could have been put into new features or solved issues. I was shocked about how nobody seemed to notice that.
However, they are not "hobby" at all. Peter Hutterer is awesome and he understands the problem very well - but as a single developer it's hard to convince a whole community, that partly does not even (want to) understand the problem. And he's responsible for libinput, not for the compositors - so it's clearly not his fault.
I think the problem lies in separated responsibilities. They are trying to keep the projects (driver, compositor, window manager) separated / independent, but in this case, the problem is spanning the whole stack.
This is such a trivial thing to fix, you just stop sending scroll events when the cursor moves.
Peter has done a great job on libinput for the most part, but he is 100% wrong about inertial scrolling (and button remapping, among a few other things).
Maybe you're right. However, this should not about individual persons / projects... this is more about that I'm still uncertain, why so many experts cannot get this thing right by just working together finding a suitable solution :-) There must by more than one way of solving this.
I'd argue that he is right about the fact, that the "driver" (libinput) should not send "simulated" events, that are not really there. Whereas the cursor movement should defintely stop the scrolling behaviour, the driver is not the place to care about this, I think it is more a compositor / window manager thing, but I'm not an expert.
However, if he would implement an opt in solution (2 config options) for lets say:
libinput.simulateKineticScrolling=1
libinput.kineticScrollingSpeed=0.22
However, they are not "hobby" at all. Peter Hutterer is awesome and he understands the problem very well - but as a single developer it's hard to convince a whole community
Wait what?
I'm pretty sure Hutterer was the one who pushed it into the App layer. He's the maintainer of libinput, and refused to do kinetic scroll within libinput (like the libsynapse driver did for X11). If he wanted to do it centrally in libinput there's nobody else to block him from doing that -- he can just do it.
I'm not sure what he did and I'm not trying to do fingerpointing. I thought he just pushed it away from libinput stating that it's the wrong place to handle it and wanting to keep libinput as "clean" as possible - even if this might be a questionable argument in this case.
To answer one of your other comments...
> If you mark them with a "this is a synthetic event" bit, the compositor/windowmanager has all the information it needs to decide whether or not to ignore the event (because, for example, the pointer moved out of one window and into another).
Yeah, this would be one of the many possible partial solutions. Don't get me wrong, I'm totally fine with this suggestion, but let's think that through:
libinput implements "simulated" events algorithm for intertial scrolling. It also would probably need a config setting for "speed" or "intensity". Nevertheless, this would not help without changes in at least one of the other layers I mentioned (Compositor, Window Manager, Apps) to either ignore or handle these events. In my opinion the App layer is the wrong place, because so every App developer / maintainer who want's to support inertial scrolling had to implement it AGAIN for his personal app which would create a tremendous amount of additional effort and different implementations acting differently. Not a great user experience...
So, the (additional) implementation has to be done somewhere between libinput and the App layer, which means either compositor or window manager.
Now, if an implementation in one of these layers is inevitable to get it working, why should it be implemented in libinput? Issues would spread over two projects, instead of one and getting pushed back and forth. This is of course my personal opinion.
Instead NOBODY implemented it and App developers and Framework Developers (QT, GTK, etc.) put in the effort to workaround this problem. That just feels wrong to me.
I wish at least one project just had shown good will to do it, in my opinion it would have been better to implement it everywhere (with optional disable) instead of nowhere, but I think it's just a too heated topic to solve it easily :-)