https://bugs.kde.org/show_bug.cgi?id=422784
--- Comment #4 from Claudius Ellsel <claudius.ell...@live.de> --- Yes, I was mostly referring to mice, although I also had touchpads in mind / wasn't really aware of the distinction. Since touchpads seem to be problematic and I also don't have one, we can make this bug about mice only. Having used the new scroll speed setting for some time I really like the faster scroll speed. So also having faster speed can have a huge impact! I also have a Logitech MX Master with this freely spinning thing, but still on Linux that was not really a nice experience and did not really fix the slow speed. Because you have to accelerate it all the time since the distance scrolled with each spin is maybe half the distance it goes on Windows. I am also looking forward to having scroll acceleration in the future. I never had it, but guess it is a pretty nice thing to have. The correct place for implementation is still a matter of discussion, afaik. There is this issue for Libinput and it might get eventually implemented there, but I think I remember a statement that this might have disadvantages (since libinput does not know the context of the scroll event). At least I think that was the reason for not implementing scroll speed and I don't see why scroll acceleration would be so much different. However, implementing it in Libinput might be still a good way. It is just not the only possible way :) Let's see how that issue moves forward. >From reading the comments there, I assume that input from the users of Libinput like KDE is probably appreciated in order to get to a nice working solution. So if you know some experts on the KDE side, maybe this issue can be continued as a collaborative effort and you can make sure that Libinput knows what you need :) -- You are receiving this mail because: You are watching all bug changes.
