Earlier quoted context omitted.
It isn't... You can see this in an open source JavaScript implementation of kinetic scrolling by Apple called PastryKit[3] using a magic number momentum * 0.9. The problem is, that on modern Linux environments, there is no clear responsibility for where scroll handling code belongs. Especially Kinetic / Inertial scrolling is handled way different than in macOS. There is libinput (for handling and redirecting input ev…
Worth mentioning that before libinput, the synapse driver handled kinetic scroll very well IMO, but AIU the developers removed the device-specific coefficients and other parameters because they said it couldn't be tested and became a mess or something. I remember looking at my Linux (Wayland, gnome3) notebook in anticipation of physical pain, at which point I switched to Mac OS permanently. To this date, I still don'…
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.