SUMMARY I have a dual screen setup side by side. When moving mouse cursor from left screen to right screen slowly, or right to left, the mouse cursor stuck at screen edge. This makes my daily work much less efficient. STEPS TO REPRODUCE 1. Setup dual screen, side by side layout. 2. Move cursor slowly from left screen to right screen. (close all windows) 3. Check if mouse cursor cross screen edge smoothly OBSERVED RESULT Mouse cursor stuck at screen edge for several seconds, the slower you move, the longer it stuck EXPECTED RESULT Mouse cursor should cross screen edge smoothly, with no delay or stuck SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20240704 KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 Kernel Version: 6.9.7-1-default (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 6700 Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7C94 System Version: 1.0 ADDITIONAL INFORMATION
This is intentional behavior. If you don't like this feature you can disable it in System Settings. Go to Mouse & Touchpad -> Screen Edges -> Set Edge Barrier to 0 px. Also you might want to uncheck Corner barrier as well if you don't want that feature.
(In reply to filip.kendes1 from comment #1) > This is intentional behavior. If you don't like this feature you can disable > it in System Settings. > Go to Mouse & Touchpad -> Screen Edges -> Set Edge Barrier to 0 px. > Also you might want to uncheck Corner barrier as well if you don't want that > feature. Thanks for the info, will change my settings. But I think there are still something to improve. The 'barriers' are for edge/corner actions, or window tile. But in case where user is not dragging a window, nor they defined any actions for this specific edge/corner, shouldn't the barriers be disabled? That will make more sense. In short, only enable corner/edge barrier when it will trigger some results.
Even setting the Edge Barrier to 0 px does not fully disable it. WHen moving the mouse slowly enough, it STILL stops at the screen edge. Please, add an option to fully & properly disable it.
I am using Wayland, mouse is set to 6400 DPI / 500 Hz polling rate (in another ticket related to the feature this seems to play a role) and identical 1440p monitors side-by-side at 100% scale (so no weird DPI setting like in that another ticket). So possibly it is related to https://bugs.kde.org/show_bug.cgi?id=489657 ? I just want to move the cursor between the rightmost pixel of the left screen to the leftmost one of the right screen (and vice versa) in exactly the same manner like between neighbouring pixels of the same screen...
(In reply to Jan Klos from comment #3) > Even setting the Edge Barrier to 0 px does not fully disable it. WHen moving > the mouse slowly enough, it STILL stops at the screen edge. > > Please, add an option to fully & properly disable it. Yes, I can also confirm that change settings to 0px won't disable it but make it less sensitive. Should be considered as a bug.
I can't reproduce the issue with 0px. Let's keep the bug open so someone could take a look at it.
This feature is also driving me crazy. I tried to disable it by changing the Edge Barrier to 0px (None), but the cursor is STILL sticky when moves between monitors. I restarted Plasma and it didn.t help. Operating System: EndeavourOS KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.10.8-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 9900X 12-Core Processor Memory: 60,5 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: ASUS
On my system (Tumbleweed, Plasma 6.2.3, wayland) setting "edge barrier" to 0 changes automatically to "none". When its "none" I cannot feel any mouse grab at all when moving between displays. Can you guys still reproduce the mouse getting stuck with edge barrier set to 0 with recent plasma versions? If so, what scaling do you have set on the different displays? I tested between 175% and 100% scales only.
(In reply to Max from comment #8) > -snip- Arch, Plasma 6.2.3, Wayland, setting "edge barrier" to "none" doesn't resolve the issue, no. 100% scaling on all three of my displays. For posterity's sake, I'm copying over some notes of mine from the related Bug 489657: > Disabling pointer acceleration *drastically reduces* how often this issue occurs. With pointer acceleration turned off, I'm only able to reproduce the issue at very very low pointer speeds. The effect is stronger than a polling rate decrease. > tl;dr for folks struggling to reproduce this issue, try turning on pointer acceleration. For folks looking for a temporary workaround, try turning off pointer acceleration.
Same here - move the mouse slowly, and you still stop at the edge, even with Edge barrier set to None. Running 6.2.4.
This still happens and does not feel as intended edge barrier is set to None but if the mouse is moved just a bit to slow it gets stuck. This is unusable with a touchpad that continues to move the cursor when the edge of it is reached.
I added a pledge: https://discuss.kde.org/t/bug-fix-cursor-stuck-at-screen-edge-when-moving-from-one-screen-to-another/32232 I hope more people will join!
I am unable to reproduce this here. As suggested, I tried with and without acceleration, two levels of acceleration, each of DPI 400 800 1600 3200 5000 (Sorry Jan no 6400 on this mouse) and polling rates 250 400 1K 4K. Monitors are 1080p on the left, 1440p on the right, level at the bottom edge. Operating System: openSUSE Tumbleweed 20250326 KDE Plasma Version: 6.3.3 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.2 Kernel Version: 6.13.8-1-default (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 31.2 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3090/PCIe/SSE2 Manufacturer: ASUS
Tested now with plasma/kwin 6.3.3, the bug is still there. Tested on two different computers with different configurations, both 200 % HiDPI on all screens. The one I'm writing this on has on the left a 3840x2400@200%, and the other 3840x2160@200%, joined side by side horizontally with a common bottom edge. The other config I have is 3840x2160@200% + 3840x2160@200% + 3840x2400@200%, also side by side horizontally with a common bottom edge. Mouse acceleration turned off in both cases.
Still reproduces on 6.3.4. It's something hinky, specifically from left to right or right to left. I tried Top/Bottom orientation and was unable to reproduce it. When I login my cursor gets stuck moving from left to right. I turn off my left display at night, and when I turn it on in the morning my cursor gets stuck going from right to left. I use 2x 1440p displays at 120% scale at 500hz poll rate. Anecdotally, the stickyness is worse in a single direction when higher values of "Edge Barrier" is set, but this is quite hard to test.
I believe I've chased this down. The super noticeable stuck on edge behavior was a regression introduced by this commit: https://invent.kde.org/plasma/kwin/-/commit/31e0e256ad534c146bd42a6ad3c22bdc16d56685 . That is fixed now, but only in 6.4 by https://invent.kde.org/plasma/kwin/-/commit/64eb6cab7e9c88940a6743cd476640b5b3008b9b . Backporting that commit to 6.3 fixed 99.9 percent of the issue for me but I could still produced stickiness on slow movements. I easily reproduced this by doing steep diagonal inputs. The last 0.1% is that Workspace::outputAt() assumes a that the screen layout is contiguous, but for certain resolution and render scales Kwin isn't generating a contiguous layout. At 1440p and 120% resolution scale for dual monitors side-by-side it creates QRectF(0,0 2133x1200) and QRectF(2134,0 2133x1200), which leaves a one pixel gap between outputs. At 125% render scale it generates QRectF(0,0 2048x1152) and QRectF(2048,0 2048x1152) which is contiguous. Some logging I hacked to Workspace::outputAt() confirmed this. pos QPointF(2133,904.333) Geometry: QRectF(0,0 2133x1200) Output Distance: 1 Geometry: QRectF(2134,0 2133x1200) Output Distance: 1 Which explains the behavior I was seeing, whichever monitor is iterated over first wins. Moving from plasmashell to kwin so the right people get their eyes on it.
Cool, great work! So now the bug only happens during odd scaling factors?
(In reply to Mads from comment #17) > Cool, great work! So now the bug only happens during odd scaling factors? As far as I can tell, yes. The quickest way to know is divide your screen resolution by your scale. If the decimal component is larger than .5 it will work correctly. If the decimal portion is smaller, you'll experience the bug. Eg. I use a left-right setup, so I take my horizontal resolution of 2560. 2560/1.2 = 2133.33 Rounds down, It will be bugged. 2560/1.25 = 2048 Good to go. 2560/1.5 = 1706.66 Not a whole number, but will round up, so still good to go.
Looking forward to 6.4! Guess I owe someone 50€? :)
Well it's not really fixed yet, I'm not a KDE developer, just a user who got annoyed enough to spend a week on my free time digging through the code to track the bug down. I can try and spend some time finding out where those values are actually initialized, and actually submit the fix but I only have a vague idea where in the source code that actually happens.
This seems to be a duplicate of bug 489657. Can someone here please confirm this and mark it as such?
Yeah, it looks like a duplicate, I'' close this one *** This bug has been marked as a duplicate of bug 489657 ***