With Libinput, there's no longer any concept of "scroll by n lines" the way there was with evdev. Instead Libinput leaves it up to the DE to take the Libinput-provided scroll angle/delta information and scale that appropriately before passing it to the UI toolkit for toolkit-specific scroll handling. We should support this, since the lack of a "scroll by n lines" feature is a regression compared to the evdev Mouse KCM. For more information, see https://gitlab.freedesktop.org/libinput/libinput/issues/185
Actually I think that Peter Hutterer suggested to do the scaling also in the toolkit and have the DE just offer a setting for the user to adjust the scaling factor which is then passed on to the toolkit. Thus I also created issues on Qt and GTK for this as well as on GNOME to be able to come up with a good solution for this (maybe also doing scaling in the DE and then pass everything to the toolkit altogether is an option). For reference: https://gitlab.gnome.org/GNOME/gnome-shell/issues/950
Just as a note, the next libinput version 1.13 will have high-resolution wheel scrolling which changes things a bit again. So might be worth waiting until that API is settled, or jumping in at https://gitlab.freedesktop.org/libinput/libinput/merge_requests/139 with comments.
*** Bug 407182 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #3) > *** Bug 407182 has been marked as a duplicate of this bug. *** How can I fix this bug temporarily?
If you want to stay with the Libinput driver, you can't. You can remove Libinput and revert to the old Evdev driver, which had this feature.
(In reply to Nate Graham from comment #5) > If you want to stay with the Libinput driver, you can't. You can remove > Libinput and revert to the old Evdev driver, which had this feature. When I try to remove libinput with dnf in Fedora 30, around 787 packages will be removed. Is there another way to do this? xorg-x11-drv-evdev is already installed.
That would be a question for the Fedora folks. :)
xorg-x11-drv-libinput is the xorg driver for libinput, removing that is sufficient. or alternatively write an xorg config snippet that assigns the evdev driver to the devices you want handled by evdev instead of libinput.
(In reply to Peter Hutterer from comment #8) > xorg-x11-drv-libinput is the xorg driver for libinput, removing that is > sufficient. or alternatively write an xorg config snippet that assigns the > evdev driver to the devices you want handled by evdev instead of libinput. Thank you for all the replies. Removing the driver does not work in Fedora. How should the snippet look like?
This would be great. I am sure it is obvious, but such UI needs also a different setting for touchpad scrolling (one of Peter's 'devilish details' which means it is hard to do in libinput), this bug really has dependency on Bug 403843 although that one has a lot fewer vote.
*** Bug 398610 has been marked as a duplicate of this bug. ***
(In reply to willemvanhulle from comment #9) > Thank you for all the replies. Removing the driver does not work in Fedora. > How should the snippet look like? Have a look at https://bugs.kde.org/show_bug.cgi?id=398610#c3 maybe that can help you.
(In reply to Tim Richardson from comment #10) > This would be great. I am sure it is obvious, but such UI needs also a > different setting for touchpad scrolling (one of Peter's 'devilish details' > which means it is hard to do in libinput), this bug really has dependency on > Bug 403843 although that one has a lot fewer vote. I think you are correct, so I added Bug 403843 as a dependency for this one.
*** Bug 411898 has been marked as a duplicate of this bug. ***
There's a WIP Libinput driver patch that would expose the API that we could hook into from the mouse KCM: https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/merge_requests/12
This was just implemented for Plasma, at least when using Wayland, with https://cgit.kde.org/plasma-desktop.git/commit/?id=0cf73170479bb271fb7498e67d38d3c6255594a4. At the moment it's Wayland only as only Wayland exposes the input hooks necessary to allow the compositor to globally scale scroll events. Doing it on X11 would require support in Libinput itself, or else support in all UI toolkits (Qt, Gtk, Electron, etc).
*** Bug 419900 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #16) > This was just implemented for Plasma, at least when using Wayland, with > https://cgit.kde.org/plasma-desktop.git/commit/ > ?id=0cf73170479bb271fb7498e67d38d3c6255594a4. > > At the moment it's Wayland only as only Wayland exposes the input hooks > necessary to allow the compositor to globally scale scroll events. Doing it > on X11 would require support in Libinput itself, or else support in all UI > toolkits (Qt, Gtk, Electron, etc). Ok, a year later - still no wheek speed adjustment on Xorg. Is there an issue in Libinput bug tracker to implement the support for this?
> Doing it on X11 would require support in Libinput itself, or else support in all UI toolkits (Qt, Gtk, Electron, etc). ftr, the xf86-input-libinput driver is *roughly* in the position of the compositor under X, so Nate's link in comment #15 is the right one. libinput has an open issue regarding wheel acceleration here: https://gitlab.freedesktop.org/libinput/libinput/-/issues/7
(In reply to Nate Graham from comment #0) > With Libinput, there's no longer any concept of "scroll by n lines" the way > there was with evdev. Instead Libinput leaves it up to the DE to take the > Libinput-provided scroll angle/delta information and scale that > appropriately before passing it to the UI toolkit for toolkit-specific > scroll handling. > > We should support this, since the lack of a "scroll by n lines" feature is a > regression compared to the evdev Mouse KCM. I tried evdev a while ago and didn't found the feature. Isn't there a confusion here with the configuration that was present in kcm_mouse in KDE4 but wasn't belonging to the driver, and was instead a KDE feature like the double-clicking ? It's still working : if you add "WheelScrollLines=8" in the "[KDE]" section of your .config/kdeglobals file, you can see the effect working in konsole and kate. The regression here is that contrary to the double-clicking, the configuration UI has not been migrated to the "General Behavior" page and the feature seems no more accessible via the GUI.
Oh, there must be something in Qt that reads that. Unfortunately it would not be a universal thing, and most apps would not respect it. Can you file a new bug report requesting that support for that be re-added in the X11 version? We would probably have to add a label to warn people that it wouldn't affect all apps.
(In reply to Nate Graham from comment #21) > Oh, there must be something in Qt that reads that. Unfortunately it would > not be a universal thing, and most apps would not respect it. > > Can you file a new bug report requesting that support for that be re-added > in the X11 version? We would probably have to add a label to warn people > that it wouldn't affect all apps. Has there been a new bug filed for that? According to a quick search there isn't, but wanted to ask just in case I missed it. If there really isn't, I would open one. Though I thing the evdev scrolling modifier does not affect all apps either. It immediatelly affects scrolling in Kate, but it doesn't affect Firefox, even after a reboot. Also, do I understand it correctly that this scroll speed setting is available with the libinput driver when Wayland is used?
(In reply to mpeter.68m0y from comment #22) > > Has there been a new bug filed for that? > According to a quick search there isn't, but wanted to ask just in case I > missed it. > If there really isn't, I would open one. I haven't filed a bug for WheelScrollLines. Go ahead ! Too much things in minds here and I'm not very good for parallelisation.
I've opened Bug 452045 for said topic. Let me know if something is not right with it, and I'll try to fix it. Please don't remind me though, that I have posted the message twice :D. After creating the bug, I haven't instantly seen my bug description, but instead the attachments and new comment box, and though my message was lost. I only noticed it wasn't when I already sent it from clipboard for the second time.. If you know how can a message be deleted, please let me know.