Description of problem: Natural scrolling no longer works after upgrading from F23 to F24 Version-Release number of selected component (if applicable): How reproducible: All the time Steps to Reproduce: 1. Toggle Natural scrolling 2. try and scroll Actual results: normal scrolling Expected results: natural scrolling Additional info: I did the upgrade using 'dnf system-upgrade ...'
I'm seeing the same thing here on a Lenovo ThinkPad X1. This laptop has both a TrackPoint (joystick-style mouse control) as well as a touchpad. Under Fedora 23, enabling natural scrolling had the expected effect on the touchpad's scrolling behavior. Under Fedora 24, the natural scrolling setting has no effect: the touchpad does not exhibit natural scrolling, regardless of the setting. I'm happy and able to provide additional hardware details, output from diagnostic commands, etc. as needed. Just let me know what you need.
I also can confirm this. A way to circumvect is detailed at: http://www.fedoraforum.org/forum/showpost.php?p=1734296&postcount=25 In sort: use xinput to manually set up libinput Natural scrolling behaviour: [jantonio@jonsy xorg.conf.d]$ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ ImPS/2 BYD TouchPad id=12 [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)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Video Bus id=8 [slave keyboard (3)] ↳ Power Button id=9 [slave keyboard (3)] ↳ pac207 id=10 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=11 [slave keyboard (3)] ↳ HP WMI hotkeys id=13 [slave keyboard (3)] ( in my case mouse has id=12 ) [jantonio@jonsy xorg.conf.d]$ xinput list-props 12 Device 'ImPS/2 BYD TouchPad': Device Enabled (142): 1 Coordinate Transformation Matrix (144): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Accel Speed (279): 0.000000 libinput Accel Speed Default (280): 0.000000 libinput Accel Profiles Available (281): 1, 1 libinput Accel Profile Enabled (282): 1, 0 libinput Accel Profile Enabled Default (283): 1, 0 libinput Natural Scrolling Enabled (284): 1 libinput Natural Scrolling Enabled Default (285): 0 libinput Send Events Modes Available (263): 1, 0 libinput Send Events Mode Enabled (264): 0, 0 libinput Send Events Mode Enabled Default (265): 0, 0 libinput Left Handed Enabled (286): 0 libinput Left Handed Enabled Default (287): 0 libinput Scroll Methods Available (288): 0, 0, 1 libinput Scroll Method Enabled (289): 0, 0, 0 libinput Scroll Method Enabled Default (290): 0, 0, 0 libinput Button Scrolling Button (291): 2 libinput Button Scrolling Button Default (292): 274 libinput Middle Emulation Enabled (293): 0 libinput Middle Emulation Enabled Default (294): 0 Device Node (266): "/dev/input/event5" Device Product ID (267): 2, 5 libinput Drag Lock Buttons (295): <no items> libinput Horizonal Scroll Enabled (268): 1 ( Locate entry for "libinput Natural Scrolling Enabled". in my case is 284 ) [jantonio@jonsy xorg.conf.d]$ xinput set-prop 12 284 0 ( To set Natural scrolling to desired value ) Unfortunately, these values are not constants and changes on each reboot/new device connected, so need to add an extra script to find and set up device properly
(In reply to Juan Antonio Martinez from comment #2) > Unfortunately, these values are not constants and changes on each reboot/new > device connected, so need to add an extra script to find and set up device > properly xinput can use device and property names instead of numbers. So you should be able to use: % xinput set-prop 'ImPS/2 BYD TouchPad' 'libinput Natural Scrolling Enabled' 0 On my box the relevant device is 'SynPS/2 Synaptics TouchPad'. Unfortunately it has no 'libinput Natural Scrolling Enabled' property, or any other property that mentions 'natural' at all. :-(
Installing "xorg-x11-drv-libinput" fixed this problem for me, with no extra "xinput" commands needed. Apparently I was using the synaptics driver before, from "xorg-x11-drv-synaptics". With "xorg-x11-drv-libinput" installed, X uses the libinput driver instead. Natural scrolling now works perfectly. I now also have working tap-to-click again. (Tap-to-click stopped working for me after upgrade to Fedora 24, but I hadn't gotten around to reporting it yet.)
I've installed xorg-x11-drv-libinput with no success. I've found this related bugs: apparently is a "feature" when latest kernel is in use: Instead of an 'ImPS/2 Logitech Wheel Mouse', an 'ImPS/2 BYD TouchPad' is found by the kernel as pointer device https://bugzilla.redhat.com/show_bug.cgi?id=1352159 https://bugzilla.kernel.org/show_bug.cgi?id=120781 Also, seems that wayland does not (yet) honours "Natural Scrolling" Anyway, until solved, xinput workaround is enought for me
I am having the same problem, but on only one of my machines (huh?). The affected machine reports this on xinput: [alex@avillacis ~]$ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ ImPS/2 BYD TouchPad id=9 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=7 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=8 [slave keyboard (3)] My pointer device is actually a Genius PS/2 mouse, not a touchpad. I have installed Openbox on the affected machine, an I have realized that inside a Openbox session, the mouse wheel actually behaves the way I want (roll with finger toward me for scrolldown, away from me for scrollup). It is only on gnome-shell that the setting gets reversed and has to be worked around with xinput.
Can confirm this issue and that the xinput fix works. On my system, the command: gsettings set org.gnome.desktop.peripherals.mouse natural-scroll true will set 'libinput Natural Scrolling Enabled' to 1 from 0, but: gsettings set org.gnome.desktop.peripherals.mouse natural-scroll false will not set it back to 0 from 1.
To summarize: This is actually several bugs: 1) kernel bug - at least some mice (in my case a PS/2 Genius) are incorrectly reported as touchpads. 2) gnome-shell bug - gsettings org.gnome.desktop.peripherals.mouse can only toggle in one way when Xorg is using libinput (NOT evdev). Not both ways. Otherwise, 1) could be worked around by setting the "reversed" setting as the default. Apparently this only affects gnome-shell with Xorg and xorg-x11-drv-libinput installed. My previously normal system had only xorg-x11-drv-evdev. I could reproduce the bug by installing xorg-x11-drv-libinput, then uninstalling xorg-x11-drv-evdev, and rebooting. I figure using xorg-x11-drv-evdev and uninstalling xorg-x11-drv-libinput would hide the bug.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.