Bug 444510

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.

Just updated to 5.23.4. Issue still exists.

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.

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

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.

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.

Still same behaviour in Plasma 5.25

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

Created attachment 151497 [details]
Mouse lag as seen in a fullscreen application

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

Does the cursor behave "weird" in normal desktop mode? or only when running a fullscreen video game?

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

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?

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

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.

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.

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

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

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.

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