since the port to version 5 the inverted scroll direction settings aren't working anymore. whatever you select scrolling direction is not changed. this is not exclusive to the touchpad kcm, also the mouse setting does not work, but I couldn't find the right component for reporting. Reproducible: Always
(In reply to Michi from comment #0) > this is not exclusive to the touchpad kcm, also the mouse setting does not > work, but I couldn't find the right component for reporting. false alarm, mouse works, only touchpad doesn't
For me the touchpad behaviour only partially changes when I set it with the mouse KCM: somewhat ironically, it changes in chromium but not in system config.
I cannot reproduce this. Reverse scrolling works fine on KDE (KF5 based at least) apps and non-KDE apps like firefox flawlessly. Could you try master branch and check if it improves? What input driver are you using? which version?
I am already using the master version of kcm-touchpad (https://aur.archlinux.org/packages/kcm-touchpad-git/), and am using the synaptics driver v 1.8.1 (https://www.archlinux.org/packages/extra/x86_64/xf86-input-synaptics/).
I have realised that it's basically that KDE4, KF5 and gtk applications are doing it all differently. I think KDE4 apps work exactly inverse to what KF5/Qt5 applications do. This also applies to the mouse.
Can confirm. I'm running KDE4 and I noticed KF5/Qt5 applications not handling reverse scrolling correctly. For me notably Kate, Konsole and QtCreator.
Can confirm a similar problem with kubuntu 15.04. Inverted scroll direction works in non-KDE apps (eg firefox), but not in KDE apps (eg konsole).
Created attachment 93043 [details] xinput log at various times I have the same bug here: reverse scroll does not work in Plasma 5 apps, although it does work on other apps such as Firefox. This applies both to mouse and touchpad. I've attached the output of xinput list-props before and after changing the settings in the system settings. As you can see all the panel does is to change Synaptics Scrolling Distance (277): 36, 35 to Synaptics Scrolling Distance (277): -36, -35 for the touchpad, and Evdev Scrolling Distance (570): 1, 1, 1 to Evdev Scrolling Distance (570): -1, -1, - for the mouse. Oddly enough when I *disable* reverse scroll for the touchpad the setting is reversed, but when I *disable* it for the mouse the setting is *not* reversed. I also used xinput to change the button map to 1 2 3 5 4 ... for both devices, again this worked only for non-plasma apps. I can provide all the debug information you need on request
After further testing I noticed that reverse scroll *does* actually work on plasma 5 apps (I tested kate, dolphin, rekonq) it just does not work with Konsole! Can the other people reporting double check? Eventally reassigne the bug
I have started to use libinput and have set the NaturalScrolling option in the xorg configuration. This has solved the whole issue for me. Back to the reported problem though, I have found that the touchpad actually did it correctly all the time, it was rather the mouse configuration that was making a mess.
I officially do not understand anything anymore. In this very moment I have a Kate window with two document in split view. I also have two mice attached to the PC: one generic Dell-branded USB and a Logitech Ultrathin Touch Bluetooth mouse. With the USB mouse both everything works correctly: both views work the same way, in inverted scroll as set up in the control panel. With the Bluetooth mouse, in the left view the mouse wheel is reversed, in the right panel it is not. These are two views of the same application! After I changed the opened file in the left view it also stopped following the settings, now both views follow the "normal" scroll direction. The only difference I found in the 2 mice, fro man xinput point of view is that the USB one has Axis Labels (286): "Rel X" (160), "Rel Y" (161), "Rel Vert Wheel" (278) while the Bluetooth one Axis Labels (286): "Rel X" (160), "Rel Y" (161), "Rel Horiz Wheel" (422), "Rel Vert Wheel" (278) May it be that the "Rel Horiz Wheel" extra axis is confusing?
I can confirm this is still a bug. I am using Fedora 22 with kf5 5.11.0. Before recent updates from Fedora I was seeing some windows honour the change and other not. Now nothing honours the settings. This is deeply annoying.
Can people please include: whether they are using synaptics or libinput the version of Plasma they are using Using libinput with old plasma will definitely not work.
Here is the version, it is not clear to me how to get the version of "plasma", whatever it is. $ apt-cache show plasma-desktop ... Version: 4:5.3.1-0ubuntu1~ubuntu15.04~ppa1 $ kwin_x11 --version kwin 5.3.1 $ kate --version kf5.kiconthemes: "Theme tree: (Breeze)" kate 5.0.0 I do not think I'm using libinput, i.e. there is no referene to it in /usr/share/X11/xorg.conf.d/ and I have this in 10-evdev.conf: Section "InputClass" Identifier "evdev pointer catchall" MatchIsPointer "on" MatchDevicePath "/dev/input/event*" Driver "evdev" EndSection If there is a better way to know, tell me.
This bug report is originally for Touchpad kcm, but some people also reported issue related to Mouse kcm. The following paragraphs are only about Mouse kcm. I did the reverse-scroll-fix in Mouse kcm of plasma 5.3.1 Internally it uses xinput and rely on some assumptions I made based on hardware I own. The assumption is: If a pointing device have "Evdev Scrolling Distance" property, positive value means traditional scroll direction, negative value means reverted scroll direction. For example, (1, 1, 1) means traditional scroll direction, (-1, -1, -1) means reverted scroll direction. If a pointing device have "Evdev Wheel Emulation" = 1, this is a device without real scroll wheels, such as a trackpoint. In this case it checks "Evdev Wheel Emulation Axes" property, the property value is an array and every 2 elements represent an axis, first element smaller than second element means traditional scroll direction, first element larger than second element means reverted scroll direction. For example, [6, 7, 4, 5] means traditional scroll direction, [7, 6, 5, 4] means reverted scroll direction. The assumptions above is based on several google searches and the behavior of my own device, so there may be pointing devices behaves differently that I don't know of. If you want to use Mouse kcm for reverted scroll direction, don't use it together with the traditional "swap-button-map-key" method, that method only works for non-qt5 apps, and is independent from the method used in Mouse kcm, if you use that method and use Mouse kcm together, you may have non-qt5 apps scrolling direction reverted twice. If you have Touchpad and also uses Touchpad kcm, I don't know how will that influence Mouse kcm settings. If you use synaptics driver in Touchpad kcm, I guess there is no issue, if you use evdev driver in Touchpad kcm, there may be conflicts caused by two kcms trying to change xinput properties at the same time, but I know nothing about Touchpad kcm code so I'm not sure. If you have manual xorg configurations on evdev driver, it may conflict with Mouse kcm, result in scroll direction reverted twice or other various status.
(In reply to lp from comment #9) > After further testing I noticed that reverse scroll *does* actually work on > plasma 5 apps (I tested kate, dolphin, rekonq) it just does not work with > Konsole! > > Can the other people reporting double check? Eventally reassigne the bug I can confirm your observation: Reversed scrolling with a mouse works for me just fine, scrolling in the console buffer does not seem to respect this setting, however.
KDE does not handle Xorg using libinput for mouse only evdev and legacy (that we can forget about). You can check what handler is being used with the xinput command. Use "xinput list" to find your mouse. Here is the output on my F22 system: $ xinput ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Microsoft Compact Optical Mouse 500 id=8 [slave pointer (2)] ⎜ ↳ Microsoft Comfort Curve Keyboard 2000 id=10 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Power Button id=7 [slave keyboard (3)] ↳ Microsoft Comfort Curve Keyboard 2000 id=9 [slave keyboard (3)] ↳ Eee PC WMI hotkeys id=11 [slave keyboard (3)] Now use xinput to list the properties of the mouse. You need the id for the mouse from above, in my example 8. $ xinput list-props 8 Device 'Microsoft Compact Optical Mouse 500': Device Enabled (150): 1 Coordinate Transformation Matrix (152): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 Device Accel Profile (274): 0 Device Accel Constant Deceleration (275): 1.000000 Device Accel Adaptive Deceleration (276): 1.000000 Device Accel Velocity Scaling (277): 10.000000 Device Product ID (269): 1118, 1847 Device Node (270): "/dev/input/event4" Evdev Axis Inversion (278): 0, 0 Evdev Axes Swap (280): 0 Axis Labels (281): "Rel X" (160), "Rel Y" (161), "Rel Vert Wheel" (273) Button Labels (282): "Button Left" (153), "Button Middle" (154), "Button Right" (155), "Button Wheel Up" (156), "Button Wheel Down" (157), "Button Horiz Wheel Left" (158), "Button Horiz Wheel Right" (159) Evdev Scrolling Distance (283): -1, -1, -1 Evdev Middle Button Emulation (284): 0 Evdev Middle Button Timeout (285): 50 Evdev Third Button Emulation (286): 0 Evdev Third Button Emulation Timeout (287): 1000 Evdev Third Button Emulation Button (288): 3 Evdev Third Button Emulation Threshold (289): 20 Evdev Wheel Emulation (290): 0 Evdev Wheel Emulation Axes (291): 0, 0, 4, 5 Evdev Wheel Emulation Inertia (292): 10 Evdev Wheel Emulation Timeout (293): 200 Evdev Wheel Emulation Button (294): 4 Evdev Drag Lock Buttons (295): 0 If you see "libinput" the KDE code will not swap the scroll direct. If you see "evdev" like above you can turn on reverse scrolling but it will not turn off. The code has an obvious bug that prevents turning off. Barry
Oh and if you do have libinput showing up the workaround is to remove the libinput xorg driver. In Fedora the package is xorg-x11-drv-libinput.
(In reply to Barry Scott from comment #17) > KDE does not handle Xorg using libinput for mouse only evdev and legacy > (that we can forget about). > > You can check what handler is being used with the xinput command. > Use "xinput list" to find your mouse. Here is the output on my F22 system: > $ xinput > ⎡ Virtual core pointer id=2 [master pointer (3)] > ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] > ⎜ ↳ Microsoft Compact Optical Mouse 500 id=8 [slave pointer (2)] > ⎜ ↳ Microsoft Comfort Curve Keyboard 2000 id=10 [slave pointer (2)] > ⎣ Virtual core keyboard id=3 [master keyboard (2)] > ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] > ↳ Power Button id=6 [slave keyboard (3)] > ↳ Power Button id=7 [slave keyboard (3)] > ↳ Microsoft Comfort Curve Keyboard 2000 id=9 [slave keyboard (3)] > ↳ Eee PC WMI hotkeys id=11 [slave keyboard (3)] > > Now use xinput to list the properties of the mouse. You need the id for the > mouse from above, in my example 8. > > $ xinput list-props 8 > Device 'Microsoft Compact Optical Mouse 500': > Device Enabled (150): 1 > Coordinate Transformation Matrix (152): 1.000000, 0.000000, > 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 > Device Accel Profile (274): 0 > Device Accel Constant Deceleration (275): 1.000000 > Device Accel Adaptive Deceleration (276): 1.000000 > Device Accel Velocity Scaling (277): 10.000000 > Device Product ID (269): 1118, 1847 > Device Node (270): "/dev/input/event4" > Evdev Axis Inversion (278): 0, 0 > Evdev Axes Swap (280): 0 > Axis Labels (281): "Rel X" (160), "Rel Y" (161), "Rel Vert > Wheel" (273) > Button Labels (282): "Button Left" (153), "Button Middle" (154), > "Button Right" (155), "Button Wheel Up" (156), "Button Wheel Down" (157), > "Button Horiz Wheel Left" (158), "Button Horiz Wheel Right" (159) > Evdev Scrolling Distance (283): -1, -1, -1 > Evdev Middle Button Emulation (284): 0 > Evdev Middle Button Timeout (285): 50 > Evdev Third Button Emulation (286): 0 > Evdev Third Button Emulation Timeout (287): 1000 > Evdev Third Button Emulation Button (288): 3 > Evdev Third Button Emulation Threshold (289): 20 > Evdev Wheel Emulation (290): 0 > Evdev Wheel Emulation Axes (291): 0, 0, 4, 5 > Evdev Wheel Emulation Inertia (292): 10 > Evdev Wheel Emulation Timeout (293): 200 > Evdev Wheel Emulation Button (294): 4 > Evdev Drag Lock Buttons (295): 0 > > If you see "libinput" the KDE code will not swap the scroll direct. > If you see "evdev" like above you can turn on reverse scrolling but it will > not turn off. > The code has an obvious bug that prevents turning off. Yes there is a bug for turning off, forgot to test that, fixed in next Plasma release, or you can apply the patch yourself: http://quickgit.kde.org/?p=plasma-desktop.git&a=commit&h=07f16ddeacdf07590fafaf94c7b6d582d663e55f > > Barry
(In reply to Barry Scott from comment #18) > Oh and if you do have libinput showing up the workaround is to remove the > libinput xorg driver. > In Fedora the package is xorg-x11-drv-libinput. Tried installing libinput driver and found indeed that makes mouse kcm not working properly. So if you want to use mouse kcm with reverse scroll, you have to remove libinput driver and restart X. I have no plan to add libinput support to mouse kcm since codebase is too old and some one is working on a new kcm unifying mouse/touchpad settings, I may add something for reverse scrolling there. http://quickgit.kde.org/?p=scratch%2Falexandermezin%2Fpointing-devices-kcm.git
(In reply to Gunter Ohrner from comment #16) > (In reply to lp from comment #9) > > After further testing I noticed that reverse scroll *does* actually work on > > plasma 5 apps (I tested kate, dolphin, rekonq) it just does not work with > > Konsole! > > > > Can the other people reporting double check? Eventally reassigne the bug > > I can confirm your observation: Reversed scrolling with a mouse works for me > just fine, scrolling in the console buffer does not seem to respect this > setting, however. I found if you have mouse with real scrolling wheel, the changes apply to non-qt5 apps immediately, but for qt5 apps you have to restart them. If you have a pointing device with emulated scrolling wheel, like a trackpoint, the changes apply to all kinds of apps immediately. I don't why qt5 apps don't pick up "Evdev Scrolling Distance" changes at runtime. Can you test if Konsole works after it is restarted?
I have the same problem, I can confirm the bug. I have kwin_x11 5.4.2 and plasmashell 5.4.2. I can make reverse scroll work in most apps with xrandr right now (for example, this does it for my touchpad: $xinput set-button-map 'SynPS/2 Synaptics TouchPad' 1 2 3 5 4 6 7 8 9 10 1 ), but even this does not work for some apps (for example, konsole), where the scrolling remains non inverted. Setting the reverse scroll option in the kde settings is not effective at all.
Quick update: I tried to use xmodmap, but that also does not work for kde 5 apps (verified in konsole and kmail). It does work with other apps (google-chrome, firefox, ...). What I have is this file in my home: $ cat .Xmodmap pointer = 1 2 3 5 4 6 7 8 9 10 11 1
Other update: reverse scrolling *does* work in okular. It does not in kmail and konsole.
Davide, please read the rest of the bug report before posting: the setting works in all KDE programs, except konsole, but they have to be restarted. And in all non KDE softwares immediately.
(In reply to lp from comment #25) > Davide, please read the rest of the bug report before posting: the setting > works in all KDE programs, except konsole, but they have to be restarted. > And in all non KDE softwares immediately. It does not work for me in kmail, even if I restart it.
(In reply to davidebasilio from comment #26) > (In reply to lp from comment #25) > > Davide, please read the rest of the bug report before posting: the setting > > works in all KDE programs, except konsole, but they have to be restarted. > > And in all non KDE softwares immediately. > > It does not work for me in kmail, even if I restart it. Never mind, it does work now. I probably had some mess in my configuration. Sorry about that.
One last observation: it seems that the setting is not preserved after resuming from suspension. For example, right after resume, kmail has standard scrolling. If I close and reopen it, it gets back to inverted scrolling.
(In reply to davidebasilio from comment #28) > One last observation: it seems that the setting is not preserved after > resuming from suspension. > > For example, right after resume, kmail has standard scrolling. > If I close and reopen it, it gets back to inverted scrolling. Yes. See https://bugs.kde.org/show_bug.cgi?id=350240
*** This bug has been confirmed by popular vote. ***
This makes the new openSUSE (42.2) almost unusable for me; I'm so used to the "inverted" scrolling. I switched to this behavior only a few days after I got myself a smartphone and it was working just fine for all applications under 42.1. Personally, I am surprised how many people still seem to use the mouse wheel the old way but obviously there are two groups of users who prefer one option respectively. So this configuration possibility MUST work. Adding to the existing comments, I, too, notice inconsistent behavior. While `xinput set-button-map "Logitech USB-PS/2 Optical Mouse" 1 2 3 5 4` fixes the problem for me for most applications untill the next reboot or unsuspend, some apps like Kate are not affected.
If you use libinput, create a /etc/X11/xorg.conf.d/60-libinput.conf : Section "InputClass" Identifier "libinput" Driver "libinput" MatchDevicePath "/dev/input/event*" Option "NaturalScrolling" "True" EndSection This enables natural scrolling for mice and trackpads.
*** This bug has been marked as a duplicate of bug 395722 ***