Bug 1352159

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).

Additional info to clarify:

The working config has:

host kernel 4.5.7-300
guest kernel 4.6.3-300

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).

Hi Branko,

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

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.

Just checked my mouse: indeed my mouse is also a Logitech mouse (M100 model).

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>"

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.,

https://bugzilla.kernel.org/show_bug.cgi?id=120781 ?

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).

(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.

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).

Same here: recognized as ImPS/2 BYD TouchPad

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

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

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.

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.

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

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

Should be noted that this bug isn't present in VMware, only in VirtualBox~

*********** 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.

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.,

(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.

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.

And the upstream bug is still open.

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

(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"?

(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.

(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.

Note: the problem doesn't exist in F25 Beta (using 4.8 kernel)

(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

(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.

oh, has this been filed against gnome yet? I have F25 here and it works,

*** Bug 1374406 has been marked as a duplicate of this bug. ***

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?

Edward: this bug here only affects the BYD devices, please file a separate bug for the gnome issue

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 :)

workaround:

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

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

(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)]

Thanks for the confirmation. Closing the bug given that the patch is already in f25 and should be in the others too.

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

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.