Bug 444510 - Mouse cursor acts weird with flat acceleration profile in plasma-wayland
Summary: Mouse cursor acts weird with flat acceleration profile in plasma-wayland
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: libinput (show other bugs)
Version: 5.24.2
Platform: Archlinux Linux
: NOR normal with 8 votes (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: wayland
Depends on:
Blocks:
 
Reported: 2021-10-27 22:44 UTC by Nathan
Modified: 2022-11-24 09:01 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.26.2


Attachments
Mouse lag as seen in a fullscreen application (114.18 KB, video/mp4)
2022-08-22 11:24 UTC, Paul Meier
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan 2021-10-27 22:44:58 UTC
SUMMARY
In plasma-wayland with the flat acceleration profile the mouse cursor will not move accurately when moving the cursor to the top left corner when a software cursor is in use (such as in video games).

STEPS TO REPRODUCE
1. Ensure the flat acceleration profile is chosen
2. Launch a game, minetest for example.
3. In minetest, click the "new" button, then the "create" button, and then the "Play Game" button
4. Try to move cursor slowly from the center to the top left corner of the screen

OBSERVED RESULT
The cursor does not accurately represent my hand movement when moving to the top left corner.

EXPECTED RESULT
The cursor should accurately represent my hand movement everywhere.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.23.2
(available in About System)
KDE Plasma Version: 5.23.2
KDE Frameworks Version: 5.87
Qt Version: 5.15.2

ADDITIONAL INFORMATION
I tested this with KDE Neon Testing Edition dated 2021-10-26 and got the same result.
The problem only occurs with the flat accleration profile on wayland. It does not happen with the adaptive accleration profile nor does it happen on the X11 session.
Comment 1 Jon Voss 2021-11-30 02:51:21 UTC
I also have this issue. Moving the mouse in a very specific direction in-game (center to top left) seems to drop input.

My profile is set to flat as well. Doesn’t seem to be as bad at higher DPI levels, but very noticeable at 800dpi.
Happens on Wayland only, no issue on X. Mouse is running at a 1000hz polling rate.
Comment 2 Jon Voss 2021-11-30 17:33:34 UTC
Just updated to 5.23.4. Issue still exists.
Comment 3 Nathan 2022-01-15 18:30:04 UTC
Just retested with the 5.24 beta (Plasma 5.91) and the issue still persists.
I would appreciate it if someone looks at this bug.
Comment 4 pete 2022-03-03 04:08:57 UTC
I can confirm this still happens on 5.24.2. On X, the pointer moves exactly as expected with the flat acceleration profile and the speed can be adjusted with the slider. On Wayland, it seems to use the adaptive profile but both the slider and profile options appear to have no effect. I hope this is seen soon by one of our lovely devs, I can imagine it being a big deal for people new that are new to KDE on distros where Wayland is the default (15-min bug?).
Comment 5 hwkiller@gmail.com 2022-03-23 04:11:34 UTC
I'm confirming this bug too. I'm not sure exactly where the issue lies, but it's consistently an issue.

OS: Arch Linux
Plasma/Kwin Version: 5.24.3
Using Flat mouse profile.

In Plasma-X11: There is no mouse input issue.
In Plasma-Wayland: There is *specifically* a problem in games when moving toward the top left (in a north-west direction). I do also have a top-left activator in kwin (present desktops).

This issue does not occur in GNOME.


I can best describe it as feeling like negative-acceleration, and as though it's 'shifting' the mouse input around. Move your mouse north east, and notice it 'feels' one-to-one, like you're on a diagonal line. Move your mouse north west, and it's no longer one-to-one: It feels like tracking is missing movement, and it wants to 'fall off' the diagonal line. More specifically, it's like the cursor is being slightly gripped by the x-axis; it shifts toward west-only, and loses some vertical movement. Even more specifically, it feels like it's losing more upward movement than westward movement, but it's failing to track well in either case. All in all, it's unable to follow a north-west diagonal line, and it feels like it's dropping movements altogether; very 'sludgy', and extremely noticeable.

Steps to reproduce:
Launch plasma-wayland. Run CSGO, STALKER: Anomaly, or other mouse-centric games.
Comment 6 Andrew 2022-03-29 04:11:53 UTC
I noticed this issue too on osu!, I play with a mouse and as hwkiller said, it kind of feels like negative-acceleration (deceleration) and for this game it make it impossible to play it. I hope that some dev can take a look at it.
Comment 7 Andrew 2022-06-19 21:54:26 UTC
Still same behaviour in Plasma 5.25
Comment 8 Summit 2022-07-30 08:50:25 UTC
Can confirm this behavior on Plasma 5.25.3.

System information:

Operating System: Arch Linux
KDE Plasma Version: 5.25.3
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.5
Kernel Version: 5.18.14-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor
Memory: 31.3 Gio of RAM
Graphics Processor: AMD Radeon RX 5700 XT
Comment 9 Paul Meier 2022-08-22 11:24:51 UTC
Created attachment 151497 [details]
Mouse lag as seen in a fullscreen application
Comment 10 Paul Meier 2022-08-22 11:25:05 UTC
I have the same issue. For me, the problem is exacerbated by slow, careful movement towards north-west. The issue seems to exist in any true fullscreen application, as I have the same issue in the looking glass client for my VMs. I've attached a video in 120fps, so the lag can be seen clearly

SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.23.2
KDE Frameworks Version: 5.97.0
Qt Version: 5.15.5
Comment 11 Vlad Zahorodnii 2022-08-22 13:17:36 UTC
Does the cursor behave "weird" in normal desktop mode? or only when running a fullscreen video game?
Comment 12 Paul Meier 2022-08-23 08:08:38 UTC
(In reply to Vlad Zahorodnii from comment #11)
> Does the cursor behave "weird" in normal desktop mode? or only when running
> a fullscreen video game?

Only in certain fullscreen applications, but not limited to games. In my case looking glass, a program which copies the framebuffer from a windows VM to my linux host, is also affected.
Comment 13 Vlad Zahorodnii 2022-08-23 08:52:59 UTC
Do you know how looking glass handles the cursor? Does it hide the compositor's cursor and render the cursor inside the window like many video games do?
Comment 14 Paul Meier 2022-08-23 15:56:40 UTC
(In reply to Vlad Zahorodnii from comment #13)
> Do you know how looking glass handles the cursor? Does it hide the
> compositor's cursor and render the cursor inside the window like many video
> games do?

I've found this in the docs:
"we need to always operate in relative mouse input mode, and since factors like windows mouse acceleration, or cursor movement by a user application may occur in the guest, we need to pass this information back so the client can render the cursor in the correct location. "

The cursor is captured and hidden by default as you've described, but I am not aware how exactly it works. 
There is an option to unhide the cursor, as well as to not capture the cursor, which does not change anything about the issue.
If I unhide and capture the cursor, there will be the windows cursor and the host cursor, which will be shown as a small dot.
The default fullscreen by looking glass is not exclusive, it is a borderless fullscreen. I habe not tried, if the issue shows up in windowed mode.
Nonetheless, the issue appears in games as well, not just in this application, as I've written before.
Comment 15 Sándor Boldizsár 2022-08-27 15:11:51 UTC
I can confirm this issue on latest Arch Linux, although some kde stuff are git because of sddm-git. I've found that it acts normal in flat acceleration mode when you set the sensitivity slider to anything but the middle one (and I guess everyone who games and actually notices this sets this to the middle and adjusts on mouse or 3rd party app). So this could be a multiplication issue or, when set to the middle one, some jank happens when skipping the acceleration adjusting.
Comment 16 Luis Schliebe 2022-09-16 09:32:14 UTC
Can confirm the issue using Nobara 36, fully updated. Bug is not present on GNOME and is also not present in X11. Changing the acceleration profile from Flat or simply dragging the sensivity slider makes it disappear, but then, inputs are not as accurate as wanted.
Comment 17 Vlad Zahorodnii 2022-10-25 08:18:51 UTC
Git commit a1191bea1826ec779e017f98edf1f0473fff79dc by Vlad Zahorodnii, on behalf of John Brooks.
Committed on 25/10/2022 at 08:18.
Pushed by vladz into branch 'master'.

wayland: Fix missing relative motion events

Use isNull on QSizeF to check for a zero delta instead of comparing it
with a default-constructed QSizeF, which in practice initializes to
(-1.0,-1.0). This caused relative motion events to be omitted if the
delta happened to be equal to (-1.0,-1.0), causing mouse jumping in some
applications.

Signed-off-by: John Brooks <john@fastquake.com>

M  +6    -6    autotests/libinput/gesture_event_test.cpp
M  +3    -3    autotests/libinput/input_event_test.cpp
M  +6    -6    autotests/libinput/mock_libinput.cpp
M  +2    -2    autotests/libinput/mock_libinput.h
M  +2    -2    autotests/libinput/pointer_event_test.cpp
M  +34   -34   autotests/test_gestures.cpp
M  +1    -1    src/backends/fakeinput/fakeinputdevice.cpp
M  +7    -7    src/backends/libinput/events.cpp
M  +3    -3    src/backends/libinput/events.h
M  +5    -3    src/backends/wayland/wayland_backend.cpp
M  +1    -1    src/backends/x11/standalone/x11_standalone_xinputintegration.cpp
M  +3    -3    src/core/inputdevice.h
M  +10   -10   src/debug_console.cpp
M  +2    -2    src/debug_console.h
M  +1    -1    src/effects.cpp
M  +3    -3    src/effects/desktopgrid/desktopgrideffect.cpp
M  +3    -3    src/effects/overview/overvieweffect.cpp
M  +3    -3    src/effects/windowview/windowvieweffect.cpp
M  +18   -18   src/gestures.cpp
M  +9    -10   src/gestures.h
M  +3    -3    src/globalshortcuts.cpp
M  +2    -2    src/globalshortcuts.h
M  +13   -13   src/input.cpp
M  +2    -2    src/input.h
M  +1    -1    src/input_event.cpp
M  +5    -5    src/input_event.h
M  +2    -3    src/input_event_spy.cpp
M  +2    -3    src/input_event_spy.h
M  +1    -1    src/libkwineffects/kwineffects.h
M  +10   -10   src/pointer_input.cpp
M  +4    -4    src/pointer_input.h
M  +3    -3    src/screenedge.cpp
M  +2    -2    src/screenedge.h
M  +3    -3    src/scripting/scriptedeffect.cpp
M  +2    -2    src/wayland/autotests/client/test_fake_input.cpp
M  +9    -9    src/wayland/autotests/client/test_wayland_seat.cpp
M  +1    -2    src/wayland/fakeinput_interface.cpp
M  +1    -2    src/wayland/fakeinput_interface.h
M  +5    -5    src/wayland/pointergestures_v1_interface.cpp
M  +2    -3    src/wayland/pointergestures_v1_interface_p.h
M  +5    -5    src/wayland/relativepointer_v1_interface.cpp
M  +3    -1    src/wayland/relativepointer_v1_interface_p.h
M  +3    -3    src/wayland/seat_interface.cpp
M  +3    -3    src/wayland/seat_interface.h

https://invent.kde.org/plasma/kwin/commit/a1191bea1826ec779e017f98edf1f0473fff79dc
Comment 18 Vlad Zahorodnii 2022-10-25 08:51:27 UTC
Git commit 3c07db610bf70796f612016c6c5354ca5c565ebd by Vlad Zahorodnii, on behalf of John Brooks.
Committed on 25/10/2022 at 08:33.
Pushed by vladz into branch 'Plasma/5.26'.

wayland: Fix missing relative motion events

Use isNull on QSizeF to check for a zero delta instead of comparing it
with a default-constructed QSizeF, which in practice initializes to
(-1.0,-1.0). This caused relative motion events to be omitted if the
delta happened to be equal to (-1.0,-1.0), causing mouse jumping in some
applications.

Signed-off-by: John Brooks <john@fastquake.com>
(cherry picked from commit a1191bea1826ec779e017f98edf1f0473fff79dc)

M  +6    -6    autotests/libinput/gesture_event_test.cpp
M  +3    -3    autotests/libinput/input_event_test.cpp
M  +6    -6    autotests/libinput/mock_libinput.cpp
M  +2    -2    autotests/libinput/mock_libinput.h
M  +2    -2    autotests/libinput/pointer_event_test.cpp
M  +34   -34   autotests/test_gestures.cpp
M  +1    -1    src/backends/fakeinput/fakeinputdevice.cpp
M  +7    -7    src/backends/libinput/events.cpp
M  +3    -3    src/backends/libinput/events.h
M  +5    -3    src/backends/wayland/wayland_backend.cpp
M  +1    -1    src/backends/x11/standalone/x11_standalone_xinputintegration.cpp
M  +3    -3    src/core/inputdevice.h
M  +10   -10   src/debug_console.cpp
M  +2    -2    src/debug_console.h
M  +1    -1    src/effects.cpp
M  +3    -3    src/effects/desktopgrid/desktopgrideffect.cpp
M  +3    -3    src/effects/overview/overvieweffect.cpp
M  +3    -3    src/effects/windowview/windowvieweffect.cpp
M  +18   -18   src/gestures.cpp
M  +9    -10   src/gestures.h
M  +3    -3    src/globalshortcuts.cpp
M  +2    -2    src/globalshortcuts.h
M  +13   -13   src/input.cpp
M  +2    -2    src/input.h
M  +1    -1    src/input_event.cpp
M  +5    -5    src/input_event.h
M  +2    -3    src/input_event_spy.cpp
M  +2    -3    src/input_event_spy.h
M  +1    -1    src/libkwineffects/kwineffects.h
M  +10   -10   src/pointer_input.cpp
M  +4    -4    src/pointer_input.h
M  +3    -3    src/screenedge.cpp
M  +2    -2    src/screenedge.h
M  +3    -3    src/scripting/scriptedeffect.cpp
M  +2    -2    src/wayland/autotests/client/test_fake_input.cpp
M  +9    -9    src/wayland/autotests/client/test_wayland_seat.cpp
M  +1    -2    src/wayland/fakeinput_interface.cpp
M  +1    -2    src/wayland/fakeinput_interface.h
M  +5    -5    src/wayland/pointergestures_v1_interface.cpp
M  +2    -3    src/wayland/pointergestures_v1_interface_p.h
M  +5    -5    src/wayland/relativepointer_v1_interface.cpp
M  +3    -1    src/wayland/relativepointer_v1_interface_p.h
M  +3    -3    src/wayland/seat_interface.cpp
M  +3    -3    src/wayland/seat_interface.h

https://invent.kde.org/plasma/kwin/commit/3c07db610bf70796f612016c6c5354ca5c565ebd
Comment 19 Andrew 2022-10-27 01:22:35 UTC
I tried KDE 5.26.2 now that the fix was merged and works perfect. No more weirdness on the movement of the cursor while playing.
Comment 20 Summit 2022-11-24 09:01:21 UTC
(In reply to Vlad Zahorodnii from comment #18)
> Git commit 3c07db610bf70796f612016c6c5354ca5c565ebd by Vlad Zahorodnii, on
> behalf of John Brooks.
> Committed on 25/10/2022 at 08:33.
> Pushed by vladz into branch 'Plasma/5.26'.
> 
> wayland: Fix missing relative motion events
> 
> Use isNull on QSizeF to check for a zero delta instead of comparing it
> with a default-constructed QSizeF, which in practice initializes to
> (-1.0,-1.0). This caused relative motion events to be omitted if the
> delta happened to be equal to (-1.0,-1.0), causing mouse jumping in some
> applications.
>
> [...]
>
> https://invent.kde.org/plasma/kwin/commit/
> 3c07db610bf70796f612016c6c5354ca5c565ebd

Thank you for this!!