| Why does this seem like such a hard problem to solve for everyone that isn’t Apple, when Apple seemingly solved the Trackpad over a decade ago? Is this it? An unknown ROI? >the highly uncertain ROI for trying to align touchpad acceleration has prevented us from proposing a system change to the default Linux settings. I can only speak for myself, but I gave up using trackpads on anything that isn’t a MacBook many years ago. Very occasionally I’ll try them and have always been disappointed. This prevents me from buying any laptop that isn’t a Mac and prevents me from running any OS that isn’t macOS on a laptop. I can’t be the only person who prioritizes the quality and feel of input devices when choosing a system. If this can make or break sales and adoption, it seems like the ROI would be pretty good. Even if we are just talking about Java app, if I’m using an obviously Java app that feels like a clunky Java app, I’ll usually find an alternative app that doesn’t feel horrible to use. I’m glad progress is being made, but I struggle to understand why it’s still a problem at all when it’s been so good for so long with Apple. They even sell Bluetooth trackpads for desktops it’s so good. |
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 events)
There is the display server
There is the compositor
There is the window manager
There is the app layer (every App, like Firefox, Gimp,
Currently kinetic scrolling is implemented on the App layer, every app has to handle the scrolling events manually to provide kinetic scrolling. This is not the case in macOS... the kinetic scrolling / rubber banding is handled within the OS.
In my opinion, the scrolling code could belong into the compositor, so that not every app developer has to write code to handle the scrolling, but still prevent unwanted effects like kinetic scrolling transfer between windows. Additionally, the kinetic scrolling approach is not configurable in Gnome... some touchpads / screens are scrolling way to fast, some are too slow...
I filed an issue[1] on cosmic in hope they'll get it right, but I don't have too high hopes that this is of much interest. On Fedora it works ok-ish with a little hack[2] called libinput-config.
[1]: https://github.com/pop-os/cosmic-epoch/issues/204
[2]: https://gitlab.com/warningnonpotablewater/libinput-config.gi...
[3]: https://stackoverflow.com/questions/38619717/need-help-disse...