Bug 1352159 - New Kernel reverse Mouse behaviour
Summary: New Kernel reverse Mouse behaviour
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 24
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1374406 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-01 20:37 UTC by Héctor Louzao
Modified: 2016-12-20 06:54 UTC (History)
34 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-13 13:26:58 UTC


Attachments (Terms of Use)
provide additional information (1.10 KB, application/x-gzip)
2016-07-04 10:53 UTC, Héctor Louzao
no flags Details
xinput_evemu_4_5_4_6 (15.21 KB, text/plain)
2016-07-04 17:56 UTC, Branko Grubić
no flags Details


Links
System ID Priority Status Summary Last Updated
Linux Kernel 120781 None None None 2016-07-12 21:06:07 UTC

Description Héctor Louzao 2016-07-01 20:37:26 UTC
Description of problem:

Facing page scrolling problem with mouse. It working reverse.

Reboot with latest Karnel problem is not solved.

Reboot with old Karnel, problem solved.


Version-Release number of selected component (if applicable):

fedora 24

How reproducible:

always

Steps to Reproduce:

Actual results:

reverse behaviour

Expected results:

as expect

Additional info:

working ->

kernel-4.5.7-200.fc23.x86_64
not working ->

kernel-4.5.7-300.fc24.x86_64 
kernel-4.6.3-300.fc24.x86_64

https://ask.fedoraproject.org/en/question/90104/new-karnel-reverse-behaviour/?answer=90128#post-id-90128

Comment 1 Erick 2016-07-02 06:50:44 UTC
Here also weird mouse behaviour with new kernel 4.6.3-300 (on host and qemu guest):

using Qemu with Fedora 24 XFCE Guest the mouse goes all over the place in the guest. It stutters (leaving mouse pointer artifacts) and text in terminals only shows up after hitting enter. The host looks ok though.
Tried reinstalling kernel on host and guest.
No result.

Booting host from 4.5.7-300 fixed the guest problems for me. Btw.mouse in 4.5.7-300 (on host and guest) is extremely responsive and with very smooth scrolling (which is quite nice, but takes getting used to).

Comment 2 Erick 2016-07-02 06:52:05 UTC
Additional info to clarify:

The working config has:

host kernel 4.5.7-300
guest kernel 4.6.3-300

Comment 3 Branko Grubić 2016-07-02 08:55:55 UTC
I can also confirm this for one of my f24 systems running Gnome. (probably desktop isn't related), reverting back from 4.6.x kernel to 4.5.x everything to normal. 
I also have another f24 system with xfce4, no issues there, at first I thought it was a libinput issues, but installed libintput driver on xfce spin, no issues. 
Switching options in system settings for natural scrolling no effect (on gnome).

Both of my systems run with PS/2 mouses, they are different models, but both logitech brand. And when I plug in the USB mouse on my affected system, it works as expected (even on 4.6.x kernel), and switching settings for natural scrolling works. 


Question for other people which are affected by this issue, are you also running with PS/2 mouse?

I'll test swicthing mouses from one system to another to see if this is specific to a one of them (I have no idea how PS/2 works).

Comment 4 Erick 2016-07-02 09:19:32 UTC
Hi Branko,

My mouse is an USB mouse (connected to KVM switch, which connects to the server via USB for mouse and keyboard).

Comment 5 Branko Grubić 2016-07-02 09:32:28 UTC
Thanks Erick,

I just did few tests on two of my systems.

One which wasn't affected works with both PS/2 devices. (F24 Xfce, kernel 4.6.3-300).

One which is affected doesn't work properly with both PS/2 devices. (F24 Gnome, kernel 4.6.3-300).

The affected system does work properly with a USB mouse using kernel 4.6.3-300. (attached early (before system start) or during the runtime).

If anyone has an idea how to test or get more information to debug this except bisecting kernel, I would love to provide them.

Comment 6 Erick 2016-07-02 16:27:33 UTC
Just checked my mouse: indeed my mouse is also a Logitech mouse (M100 model).

Comment 7 Peter Hutterer 2016-07-04 07:31:35 UTC
Record scroll wheel motion with evemu-record please and attach it here. That should show us whether it's really the kernel or something in userspace.

ftr, REL_WHEEL should show -1 for "down" (wheel towards you) and 1 for "up" (wheel away from you). Check that on both kernels, if the output from the mouse is the same then it's definitely userspace.

If this under X please also paste the output of xinput list-props "<your mouse device>"

Comment 8 Héctor Louzao 2016-07-04 10:53:05 UTC
Created attachment 1175954 [details]
provide additional information

xinput --list 
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ ImExPS/2 BYD TouchPad                   	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)]
    ↳ HD Webcam C525                          	id=8	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=9	[slave  keyboard (3)]

step :

first down (close to me) then up

Regards.,

Comment 9 Mamoru TASAKA 2016-07-04 14:16:07 UTC
https://bugzilla.kernel.org/show_bug.cgi?id=120781 ?

Comment 10 Branko Grubić 2016-07-04 17:56:17 UTC
Created attachment 1176146 [details]
xinput_evemu_4_5_4_6

Looks like this is related to that kernel bug, same here, device is recognized differently on two different kernels.

Also I have some strange results for evemu-record (I double checked this, I have no idea how this looks the same).

Comment 11 Peter Hutterer 2016-07-06 02:28:22 UTC
(In reply to Héctor Louzao from comment #8)
> Created attachment 1175954 [details]
> provide additional information
> 
> xinput --list 

[...]

fwiw, that's list, not list-props. the latter would show which options are currently enabled/disabled on the device (e.g. touchpad, different scroll methods, etc.)

But the output matches what Branko attached, both of you have the mouse detected as BYD touchpad so the fault appears to be the bug Mamoru linked to.

Comment 12 Tom Horsley 2016-07-06 13:54:29 UTC
Over in bug 1352325, I reported the same problem with my mouse inside a Windows 10 KVM, but it is worse than just inside the QEMU instance - it seems to "bleed out" into the host system and make various windows flake out in strange and wondrous ways (I have a couple of video links in that bug to show this). Weirdly it is only a problem in the Windows 10 machine. No mouse problems in old Windows XP and CentOS virtual machines running on the same host.

I'm using a USB trackball on the host (Kensington Expert Mouse).

Comment 13 Hedayat Vatankhah 2016-07-11 12:05:00 UTC
Same here: recognized as ImPS/2 BYD TouchPad

Comment 14 Joachim Frieben 2016-07-12 21:06:08 UTC
Natural scrolling actually -is- enabled in a GNOME on Xorg session bot -not- in a GNOME on Wayland session. What is curious is that even though I am using a PS/2 mouse attached to my notebook, the only pointing device reported by 'xinput --list' is an 'ImPS/2 BYD TouchPad'. This issue seems to be caused by https://bugzilla.kernel.org/show_bug.cgi?id=120781 and also affects the current Fedora development 25 (rawhide) tree.

$ xinput list-props 11
Device 'ImPS/2 BYD TouchPad':
	Device Enabled (140):	1
	Coordinate Transformation Matrix (142):	1.000000, 0.000000, 0.000000, 0.00000
0, 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/event6"
	Device Product ID (267):	2, 5
	libinput Drag Lock Buttons (295):	<no items>
	libinput Horizonal Scroll Enabled (268):	1

Comment 15 Joachim Frieben 2016-07-13 04:24:30 UTC
After booting kernel-4.5.5-300.fc24 instead of kernel-4.6.3-300.fc24, 'xinput --list' reports the correct pointer device, namely 'ImPS/2 Logitech Wheel Mouse', and normal scrolling mode is restored as expected.

$ xinput list-props 11
Device 'ImPS/2 Logitech Wheel Mouse':
	Device Enabled (140):	1
	Coordinate Transformation Matrix (142):	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):	0
	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

Comment 16 Kent Engström 2016-07-21 08:03:07 UTC
I am also affected by this problem. When using the Fedora 24 kernel
kernel-4.6.3-300.fc24.x86_64 on my Dell desktop with a PS/2-connected HP mouse, the mouse wheel direction is reversed as compared to my earlier experience, and I see "ImPS/2 BYD TouchPad" in the output from "xinput".

I tested building a custom kernel to test this out (and to learn how to build a custom Fedora kernel :-), setting CONFIG_MOUSE_PS2_BYD=n in the configuration (which required patching away the "expert" flag from that config option).

With my new 4.6.4-301.kent.fc24.x86_64 kernel, I now see "ImPS/2 Logitech Wheel Mouse" in the output from "xinput", and the mouse wheel behaves like it used to do.

Comment 17 Benjamin Tissoires 2016-07-21 09:51:27 UTC
Quick update on this one.

Looks like upstream is aware of the issue and is working on it (see https://patchwork.kernel.org/patch/9204273/).

The patch still is not finished and we need to wait for its inclusion in the input tree at least to backport it in Fedora. Thanks for being patient.

Comment 18 Piotr Popieluch 2016-08-18 09:31:08 UTC
Experiencing the same issue Fedora 24 guest on VirtualBox running on Windows 7 on the host, Lenovo Thinkpad T440s.

Mouse is recognised as ImExPS/2 BYD TouchPad
In evemu-record crollwheel "away from me" shows -1 and towards me shows 1
Changing the natural scroll setting in gnome-settings has no effect.
4.6.5-300.fc24.x86_64

Comment 19 David Nadle 2016-09-06 19:31:24 UTC
Probable duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1349600

workaround is to run:
$ xinput set-prop 'ImExPS/2 BYD TouchPad' 'libinput Natural Scrolling Enabled' 0

Comment 20 Mromson 2016-09-16 12:28:34 UTC
Should be noted that this bug isn't present in VMware, only in VirtualBox~

Comment 21 Laura Abbott 2016-09-23 19:21:28 UTC
*********** MASS BUG UPDATE **************
 
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs.
 
Fedora 24 has now been rebased to 4.7.4-200.fc24.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 25, and are still experiencing this issue, please change the version to Fedora 25.
 
If you experience different issues, please open a new bug report for those.

Comment 22 Héctor Louzao 2016-09-24 14:45:32 UTC
E: 0.000001 0002 0008 -001	# EV_REL / REL_WHEEL            -1
E: 0.000001 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +0ms
E: 5.228275 0002 0008 0001	# EV_REL / REL_WHEEL            1
E: 5.228275 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +5228ms

REL_WHEEL should show -1 for "down" (wheel towards you) and 1 for "up" (wheel away from you).

uname -r : 4.7.4-200.fc24.x86_64

Regards.,

Comment 23 David Nadle 2016-09-24 15:33:36 UTC
(In reply to Laura Abbott from comment #21)
> Fedora 24 has now been rebased to 4.7.4-200.fc24.  Please test this kernel
> update (or newer) and let us know if you issue has been resolved or if it is
> still present with the newer kernel.

I find that the issue is still present in 4.7.4-200.fc24.x86_64 in a VirtualBox guest.

Comment 24 Joachim Frieben 2016-09-24 19:17:16 UTC
For kernel-4.7.4-200.fc24, on real hardware, a PS/2 mouse is still erroneously identified as an "ImPS/2 BYD TouchPad":

$ xinput
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ ImPS/2 BYD TouchPad                     	id=11	[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)]
    ↳ Sleep Button                            	id=8	[slave  keyboard (3)]
    ↳ LITE-ON Technology USB NetVista Full Width Keyboard.	id=9	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=10	[slave  keyboard (3)]
    ↳ ThinkPad Extra Buttons                  	id=12	[slave  keyboard (3)] .

As a consequence, scrolling behaviour is still inverted.

Comment 25 Mamoru TASAKA 2016-09-26 15:21:11 UTC
And the upstream bug is still open.

Comment 26 isrvr-lptp1 2016-10-22 07:12:22 UTC
I can confirm that the work around discussed by David works, here is mine:

xinput set-prop 'ImPS/2 BYD TouchPad' 'libinput Natural Scrolling Enabled' 0

Comment 27 Joachim Frieben 2016-10-22 12:18:41 UTC
(In reply to isrvr-lptp1 from comment #26)
What about opening (GNOME panel) menu "Settings > Mouse & Touchpad" and changing "Natural Scrolling" from "Off" to "On"?

Comment 28 isrvr-lptp1 2016-10-22 12:31:34 UTC
(In reply to Joachim Frieben from comment #27)
No, it does not work. It must be a Gnome bug; or the kernel or the driver defaults to natural scrolling.

Comment 29 isrvr-lptp1 2016-10-22 12:32:31 UTC
(In reply to Joachim Frieben from comment #27)
No, it does not work. It must be a Gnome bug; or the kernel or the driver defaults to natural scrolling.

Comment 30 Hedayat Vatankhah 2016-10-22 19:10:27 UTC
Note: the problem doesn't exist in F25 Beta (using 4.8 kernel)

Comment 31 Peter Hutterer 2016-10-23 23:02:56 UTC
(In reply to isrvr-lptp1 from comment #29)
> (In reply to Joachim Frieben from comment #27)
> No, it does not work. It must be a Gnome bug; or the kernel or the driver
> defaults to natural scrolling.

the touchpad isnt' exposed as touchpad with this kernel, it looks like a relative mouse so the gnome panel (and libinput, and everything else above the kernel) doesn't know there's a touchpad present. if you change the mouse to natural scrolling, this touchpad should switch too (but then obviously your other mouse if you have any will too)

gsettings set org.gnome.desktop.peripherals.mouse natural-scroll true

or toggle the switch in the control panel

Comment 32 David Nadle 2016-10-24 01:54:18 UTC
(In reply to Peter Hutterer from comment #31)
> gsettings set org.gnome.desktop.peripherals.mouse natural-scroll true
> 
> or toggle the switch in the control panel

No, there is a gsettings bug:

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.

Comment 33 Peter Hutterer 2016-10-24 02:29:31 UTC
oh, has this been filed against gnome yet? I have F25 here and it works,

Comment 34 Peter Hutterer 2016-11-01 05:32:49 UTC
*** Bug 1374406 has been marked as a duplicate of this bug. ***

Comment 35 Edward O 2016-11-02 22:43:55 UTC
I hit the same problem after upgrading from F23 to F24 on a Dell E7440, with a touchpad that seems otherwise correctly detected.

The workaround worked for me to:

xinput set-prop 'AlpsPS/2 ALPS DualPoint TouchPad'  'libinput Natural Scrolling Enabled' 0

but somehow this just seem to be the gnome bug detailed in #32 (unticking the checkbox does not work), and not the original kernel detection bug... Shouldn't this one be reported separately so the fix can be backported?

Comment 36 Peter Hutterer 2016-11-02 22:47:30 UTC
Edward: this bug here only affects the BYD devices, please file a separate bug for the gnome issue

Comment 37 Benjamin Tissoires 2016-11-17 10:26:45 UTC
FYI, a revert of the BYD detection is scheduled to be pushed to Linus' tree:
https://git.kernel.org/cgit/linux/kernel/git/dtor/input.git/commit/?h=for-linus&id=e9fb7cc63801d3dc71b60ca11c4d08f68f879a53

So we will be able to close this bug soon :)

Comment 38 customercare 2016-12-08 16:28:46 UTC
workaround:

xinput set-prop 11 289 -0.5 2>/dev/null  ( movement speed )
xinput set-prop 11 294 0 2>/dev/null     ( reverse scrolling )

Comment 39 Piotr Popieluch 2016-12-13 11:37:55 UTC
Mouse behaviour seems to work correctly now for me on F24 in VirtualBox 5.1.10 on Windows 7.

4.8.13-200.fc24.x86_64

Comment 40 Joachim Frieben 2016-12-13 13:17:00 UTC
(In reply to Joachim Frieben from comment #24)
In contrast with comment 24, the PS/2 mouse is now correctly detected with kernel-4.8.13-300.fc25:

$ xinput
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ ImPS/2 Logitech Wheel Mouse             	id=11	[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)]
    ↳ Sleep Button                            	id=8	[slave  keyboard (3)]
    ↳ LITE-ON Technology USB NetVista Full Width Keyboard.	id=9	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=10	[slave  keyboard (3)]
    ↳ ThinkPad Extra Buttons                  	id=12	[slave  keyboard (3)]

Comment 41 Benjamin Tissoires 2016-12-13 13:26:58 UTC
Thanks for the confirmation. Closing the bug given that the patch is already in f25 and should be in the others too.

Comment 42 Erik Streb del Toro 2016-12-19 06:22:48 UTC
For users of Fedora 24: You can use the following command to permanently set the scroll direction (natural scrolling or no):

    gsettings set org.gnome.desktop.peripherals.touchpad natural-scroll false

To enable it use true instead of false. And touchpad is only needed for mice in Fedora 24 (as they are recognized as touchpads). Otherwise use ".mouse" instead of ".touchpad".

See this forum thread: http://forums.fedoraforum.org/showthread.php?p=1778162&posted=1#post1778162

Comment 43 isrvr-lptp1 2016-12-20 06:54:50 UTC
This seems to work good, but there is still a bit of bug, when you try to switch window, scrolling seems to get confused, when you scroll up, the pages scrolls down a bit then scrolls up.


Note You need to log in before you can comment on or make changes to this bug.