I have "Present Windows" effect bound to the upper-left corner of the screen. If I move mouse cursor there too fast, the pointer stucks several pixels away from the corner and doesn't trigger the effect. It only triggers if I move it really slowly. This bug shows itself also as a visual glitches if moving the cursor to any screen edge: pointer moves rather smoothly, but as it approaches the edge, it starts jumping noticeably. It only occurs in the Wayland session.
Do you have windows in the corner? If yes could you try to move them away and test whether that changes it? We have a special handling for Xwayland 1.18, which might make the cursor jump at 0/0
(In reply to Martin Gräßlin from comment #1) > Do you have windows in the corner? If yes could you try to move them away > and test whether that changes it? We have a special handling for Xwayland > 1.18, which might make the cursor jump at 0/0 I have a Plasma panel on that edge of the screen (which is set to "Always visible", so no windows can overlap it). Moving it around didn't help. BTW, I use xorg-server 1.19.0, KDE Frameworks 5.29.0, and Wayland 1.12.0.
Still an issue in Plasma 5.9.1. It makes "Active Screen Edge Actions" feature (almost) useless in Wayland :( It behaves in a following manner: when I'm moving cursor, each time it jumps by some vector (dx, dy), which depends on the speed of cursor movement. It seems like there is a following check: if (x+dx, y+dy) is outside the visible area, just ignore that move, and thus make the cursor stuck at some position away from the border. If I move slowly, then (dx, dy) is small, which allows me to come closer to the border and eventually touch it (thus triggering the edge action). But if I keep moving fast, the cursor is stuck. The proper behavior would be to move cursor exactly at the border instead.
*** Bug 376317 has been marked as a duplicate of this bug. ***
https://phabricator.kde.org/D5182 should hopefully improve the situation.
I rebuilt KWin with that patch. Unfortunately, it didn't help that much: it's still reproducible.
Git commit 0bb587dcb9de0a3bc688019fd66b224e713b3501 by Martin Gräßlin. Committed on 27/03/2017 at 05:08. Pushed by graesslin into branch 'master'. Ensure PointerInputRedirection::processMotion finishes prior to warping Summary: Consider the following situation: we have three InputEventFilter linked in the sequence A - B - C. The input filters are processing pointer motion events. The expected behavior is that the new motion is processed in the sequence A -> B -> C So far this did not work correctly if the pointer gets warped during the processing. If e.g. filter B warps the pointer we get a motion sequence: A (1) -> B (1) -> A (2) -> B (2) -> C (2) -> C (1) The filters following the one warping the pointer get first the newer than the older position. This is obviously wrong. Unfortunately it is not just a theoretical condition, but a condition happening when interacting with the screenedges, which warp the pointer. This change introduces a PositionUpdateBlocker in PointerInputRedirection::processMotion to ensure that a processMotion call finishes prior to the next update. If the PositionUpdateBlocker is blocked the new position gets scheduled and processed once the PositionUpdateBlocker gets destroyed. With this we get the expected sequence for B warping pointer: A (1) -> B (1) -> C (1) -> A (2) -> B (2) -> C (2) This should hopefully improve the interaction with screen edges on Wayland. Test Plan: Added an auto test demonstrating the issue of incorrect ordering caused by screenedges. Prior to the change the test is failing. Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D5182 M +46 -0 autotests/integration/pointer_input.cpp M +49 -0 pointer_input.cpp https://commits.kde.org/kwin/0bb587dcb9de0a3bc688019fd66b224e713b3501
The problem still persists in kwin 5.11.4, qt 5.9.3, kwayland 5.40.0 and intel graphics on my archlinux notebook. I also noticed that activating the corner with a mouse works most of the time while using the touchpad doesnt.
I'm seeing this bug too, with the latest-and-greatest installed. Software setup: kde-frameworks 5.42 kde-plasma 5.11.95 libinput 1.9.4 (but also with 1.8.3)
*** Bug 390258 has been marked as a duplicate of this bug. ***
*** Bug 392563 has been marked as a duplicate of this bug. ***
Problem persists for Gentoo Linux on Thinkpad T450s with Qt 5.11rc2 libinput 1.10.6 KDE frameworks 5.46 Plasma 5.12.90
I can confirm that this bug also affects a fully-up-to-date installation on Fedora 28 (just launched). It affects only the Wayland session, and not the Xorg session. Moreover, it affects all effects such as Present Windows, Application Launcher etc. Makes 'Screen Edges' features useless.
*** Bug 395886 has been marked as a duplicate of this bug. ***
Git commit 1e4703a719599d1587f5e43c0650bcac471450e7 by Vlad Zagorodniy. Committed on 15/07/2018 at 20:05. Pushed by vladz into branch 'Plasma/5.13'. [wayland] Confine pointer to screen geometry Summary: If the new pointer position is "off screen", PointerInputRedirection just ignores that new position. So, pointer remains on its previous position. In some particular cases, like reaching default panel, it degrades desktop experience because one have to slowly move pointer in order to reach what he/she wants. This change addresses that problem by confining the new pointer position to screen geometry. FIXED-IN: 5.13.4 Test Plan: Ran tests Reviewers: #kwin, graesslin Reviewed By: #kwin, graesslin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D14036 M +93 -0 autotests/integration/pointer_input.cpp M +12 -6 pointer_input.cpp https://commits.kde.org/kwin/1e4703a719599d1587f5e43c0650bcac471450e7