SUMMARY I have a 2-monitor setup (left|right, with left as primary, both monitors 1440p) and I use a 115% fractional scaling level on both monitors (Wayland). This causes the cursor to "stick" (behaves like the new "edge barrier" feature) to the right edge of the left screen when trying to move onto my right monitor. This only happens in that direction (right->left is not sticky at all unless edge barrier is switched on, but that makes the left->right direction even stickier). This doesn't happen at 100%, 200%, or 125% scale, but does seem to happen at 110% and 120%, and a number of other scaling factors that aren't a multiple of 25 (though not all). This was also happening prior to plasma 6.1 (before the edge barrier feature was introduced). I also tested at 1080p, and whilst I don't see the same behaviour at 115%, I do at 110%, though it is a little less noticeable. STEPS TO REPRODUCE 1. Configure 2 monitors side-by-side, left primary, with one of the problematic resolution/scaling combinations (e.g. 1440p/115% or 1080p/110%) in display configuration (system settings) 2. Switch off edge barrier in screen edges (system settings) 3. Move mouse slowly from left screen onto right OBSERVED RESULT Mouse cursor gets stuck at screen border EXPECTED RESULT Mouse cursor moves freely onto right screen SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux with Plasma 6.1.1 KDE Plasma Version: 6.1.1 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 Graphics Platform: Wayland
fwiw if the cursor is stuck at the top or at the bottom, it might be because the two screens have different sizes, and you are trying to move the cursor into empty space.
(In reply to fanzhuyifan from comment #1) > fwiw if the cursor is stuck at the top or at the bottom, it might be because > the two screens have different sizes, and you are trying to move the cursor > into empty space. Thanks, but that isn't the issue - both monitors are the same size and have the same fractional scaling set. Thee cursor isn't actually completely stuck, as moving the mouse faster overcomes whatever inertia is stopping it from reaching the other monitor. It's very similar behaviour to the new "edge barrier" feature, except it only happens in one direction (left monitor -> right monitor) and at specific fractional scaling levels, and it happens even when that feature is switched off (and indeed was happening before that feature existed).
I tested on two 1920x1080 monitors, with both scales set to 110% (wayland, git build, arch linux), and cannot notice any cursor resistance when slowly moving cursor from left screen to right screen, or right to left.
I also cannot reproduce the issue with a 4k screen at 225% scale and a 1080p screen at 100-115% scale.
This is most likely because of the fractional part in the display size, the two displays don't actually touch. To cross over to the other display, a single mouse event has to move the cursor as far as the distance between the two screens. In this case, with 1440p + 115% scale, the display is 2226.087 logical units wide, and the next one is at position 2227, so the distance is about as high as it can be.
(In reply to Zamundaaa from comment #5) > This is most likely because of the fractional part in the display size, the > two displays don't actually touch. To cross over to the other display, a > single mouse event has to move the cursor as far as the distance between the > two screens. > In this case, with 1440p + 115% scale, the display is 2226.087 logical units > wide, and the next one is at position 2227, so the distance is about as high > as it can be. In this case the effect would be more noticeable with a high polling rate mouse.
(In reply to fanzhuyifan from comment #6) > (In reply to Zamundaaa from comment #5) > > This is most likely because of the fractional part in the display size, the > > two displays don't actually touch. To cross over to the other display, a > > single mouse event has to move the cursor as far as the distance between the > > two screens. > > In this case, with 1440p + 115% scale, the display is 2226.087 logical units > > wide, and the next one is at position 2227, so the distance is about as high > > as it can be. > > In this case the effect would be more noticeable with a high polling rate > mouse. Ah, that makes a lot of sense! I believe I do have a higher-than-average polling rate mouse (8000 DPI max I think, but I don't run it at that), so I'll try playing with that this evening. In that case, would there anything we could do to "fix" this? Perhaps by adjusting the screen boundary logic? I'm not at all familiar with how this works, or if it's even a KDE-specific thing.
(In reply to Sam from comment #7) > (In reply to fanzhuyifan from comment #6) > > (In reply to Zamundaaa from comment #5) > > > This is most likely because of the fractional part in the display size, the > > > two displays don't actually touch. To cross over to the other display, a > > > single mouse event has to move the cursor as far as the distance between the > > > two screens. > > > In this case, with 1440p + 115% scale, the display is 2226.087 logical units > > > wide, and the next one is at position 2227, so the distance is about as high > > > as it can be. > > > > In this case the effect would be more noticeable with a high polling rate > > mouse. > > Ah, that makes a lot of sense! I believe I do have a higher-than-average > polling rate mouse (8000 DPI max I think, but I don't run it at that), so > I'll try playing with that this evening. In that case, would there anything > we could do to "fix" this? Perhaps by adjusting the screen boundary logic? > I'm not at all familiar with how this works, or if it's even a KDE-specific > thing. Ignore 8000 DPI, I need to learn to proof read - polling rate is 1,000 Hz. Not sure if this is super high (from a brief internet search, a lot of mice don't seem to advertise their polling rate), but I'll try with other mice I have this evening and see what happens.
> In that case, would there anything we could do to "fix" this? Perhaps by adjusting the screen boundary logic? Yep, it needs to be changed to just allow jumps between screens if the distance is small enough
Have just tested with a 125Hz mouse and couldn't reproduce the issue anywhere near as easily; I had to move the mouse extremely slowly to the point that I wouldn't notice it if I wasn't looking for it. This is quite a contrast from the 1,000Hz mouse that I've been experience the issue with, which can happen at a much higher speed, which seems to correlate with @Zamundaaa's theory. Thanks for the help everyone!
The edge barrier feature was driving me crazy, but indeed, changing scaling to 150% fixed the problem (somehow I had it set it 175% before). I have two 4k monitors 3840x2160px.
I can reproduce this issue on Arch + Wayland. In my case I have a 4000hz mouse set to 8000 dpi. I have set 'None' pointer acceleration with a -0.95 'Pointer Speed' in the mouse settings so that it moves at a reasonable speed. Both monitors are 1920x1080 and are at 100% scaling (untouched). If a single event (or batch of events?) big enough to 'skip' into the next monitor is required to move between monitors, then a combination of high DPI and polling rate is likely required to reproduce this issue. This bug is probably reproducible on any setup if 'Pointer Speed' is set to a low enough value so that this gap required to skip into the next monitor becomes wider.
I've also got this issue, Arch + Wayland (Plasma 6.2.2) with three displays. From left to right: 1. 1080p, vertical orientation, 100% scaling 2. 1080p, horizontal orientation, 100% scaling 3. 1440p, horizontal orientation, 100% scaling My (USB-A) mouse polls USB at 1000hz (confirmed using evhz). Indeed, lowering the polling rate lessens the issue. Two notes: - Disabling display 1 still leaves the issue between 2 and 3. Disabling 3 still leaves the issue between 1 and 2. - 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.
Confirmed to still be present in 6.4. I have a 1080x1920 display on the left, and a 2560x1440 display on the right, both are set to 100% scaling. Mouse acceleration is off, and the polling rate is 1000 Hz.
Created attachment 182540 [details] Showcasing a bug described in the report I was advised to share a video showcasing the bug, so here it is.
*** Bug 489862 has been marked as a duplicate of this bug. ***
From the closed duplicate bugreport I posted this: (In reply to Mads from comment #12) > 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!
*** Bug 506329 has been marked as a duplicate of this bug. ***
i just tried this out and it's unrelated to the screen scaling for me. for me it only appears when using <= -0.5 pointer speed (no acceleration) using a 4k and a 1080p monitor
Reproduced Conclusions: I did some iterations and realised that in case the pointer acceleration is on, the problem seems to be related to which monitor is detected first. If you move the cursor from the 1st detected monitor to the 2nd detected monitor, the barrier comes up, but does not come up when moving from the 2nd detected monitor to the 1st detected monitor. I used 2 different mice for the 1st 2 iterations (both mice for 2 iterations each, not one or the other), but when I realised they were giving similar results, just stuck with one. These 2 mice were Steelseries gaming mice, with DPIs > 5000. After the 6th iteration, I tried a Dell Wireless mouse (with "normal" DPI) to get similar results. Then I turned off pointer acceleration (speed still -1) and the bug appeared in both directions regardless of which monitor was detected first. Following is the iterations I tried: - D1 and D2 are 2 separate physical monitors, both 1920x1080. D1 has 100Hz capability. - portA and portB are the 2 ports on the GPU I connected those monitors to, both DisplayPort™ ____ 1 ____ Settings: Left monitor [D1-portA] - Res: 1920x1080 Refresh: 100Hz Scaling: 100% [Set as default monitor] Right monitor [D2-portB] - Res: 1920x1080 Refresh: 60Hz Scaling: 100% Mouse - Speed: -1 Acceleration: Enabled Edge barrier: None Observation: The perceived edge barrier only happens when moving from the Left monitor to Right monitor. When moving from the right to the left one, no barrier is perceived. ____ 2 ____ Settings: Right monitor [D1-portA] - Res: 1920x1080 Refresh: 100Hz Scaling: 100% [Set as default monitor] Left monitor [D2-portB] - Res: 1920x1080 Refresh: 60Hz Scaling: 100% Mouse - Speed: -1 Acceleration: Enabled Edge barrier: None Observation: The perceived edge barrier only happens when moving from the Right monitor to Left monitor. ____ 3 ____ Swapped ports while the computer was running Inserted D2 first and D1 second Settings: Left monitor [D1-portB] - Res: 1920x1080 Refresh: 60Hz/100Hz (tried both) Scaling: 100% Right monitor [D2-portA] - Res: 1920x1080 Refresh: 60Hz Scaling: 100% Mouse - Speed: -1 Acceleration: Enabled Edge barrier: None Observation: The perceived edge barrier only happens when moving from the Right monitor to Left monitor. ____ 4 ____ Settings: Right monitor [D1-portB] - Res: 1920x1080 Refresh: 60Hz Scaling: 100% Left monitor [D2-portA] - Res: 1920x1080 Refresh: 60Hz Scaling: 100% Mouse - Speed: -1 Acceleration: Enabled Edge barrier: None Observation: The perceived edge barrier only happens when moving from the Left monitor to Right monitor. ____ 5 ____ Took out D2 and put it back in Settings: Right monitor [D1-portB] - Res: 1920x1080 Refresh: 100Hz Scaling: 100% Left monitor [D2-portA] - Res: 1920x1080 Refresh: 60Hz Scaling: 100% Mouse - Speed: -1 Acceleration: Enabled Edge barrier: None Observation: The perceived edge barrier only happens when moving from the Right monitor to Left monitor. ____ 6 ____ Live Swapped ports again Inserted D2 first Settings: Left monitor [D1-portB] - Res: 1920x1080 Refresh: 100Hz Scaling: 100% Right monitor [D2-portA] - Res: 1920x1080 Refresh: 60Hz Scaling: 100% Mouse - Speed: -1 Acceleration: Enabled Edge barrier: None Observation: The perceived edge barrier only happens when moving from the Right monitor to Left monitor. ____ Removed tag for "default monitor" because I tested setting either of them as default in all conditions Finally saying, I tested these under very slow conditions thanks to the -1 pointer speed. The fastest I was getting with acceleration off, was 2mm per pixel-on-screen and the Dell one was 5mm per pixel on screen, which I then purposefully moved slowly. This caused a greater amount of up/down movement per right/left movement which might matter depending upon the transfer function used. Either way, the barrier was set to "None", so the relevant transfer function should not have been invoked in the first place.
@Tom Dzmelyk seems to have fixed it in the other bug? https://bugs.kde.org/show_bug.cgi?id=489862#c16 But then later on in the thread he said it's not fixed yet... > 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. Also this user says they fixed it by switching from Wayland back to X11, but I'm not going to switch window managers just to fix such a minor (yet frustrating) issue: https://discuss.kde.org/t/6-1-plasma-mouse-sticking-a-bit-more-to-screen-edges/17437/13?u=domarius Anyway, the issue is still happening for me, with Edge Barrier set to None and Corner Barrier unchecked. Here's my info: Operating System: EndeavourOS KDE Plasma Version: 6.4.3 KDE Frameworks Version: 6.16.0 Qt Version: 6.9.1 Kernel Version: 6.15.8-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-6700K CPU @ 4.00GHz Memory: 32 GiB of RAM (31.3 GiB usable) Graphics Processor: NVIDIA GeForce RTX 2060 SUPER On a seperate note, the fact that it's on by default is its own issue which has a great discussion here and this user points out how easy it is to find a general dislike towards this feature by searching for "Edge Barrier" and finding many results asking about this "bug" or how to turn it off. https://discuss.kde.org/t/newly-introduced-edge-barrier-default-value-should-be-0/26793/8?u=domarius
Also the title of the bug is misleading because I don't have any scaling and I still experience the issue.
A couple weeks ago, I had to reset/reinstall Plasma for an unrelated reason, and the bug was just gone, as simple as that
Here's a video of my mouse sticking to the edges, with Edge barrier set to "None". Notice it's intermittent, about 50% of the time. https://youtu.be/SVk0ogkp11o
This is fixed by switching from Wayland to X11, for my distro I had to type "yay plasma-x11-session", after logging out and switching to X11, no more sticky edges! Also my various screen recording software is working! I had one for gifs, one for videos, neither worked, nor any alternatives. Until I switched to X11.
Do exist any workaround for this ? In multy monitor setup with top and bottom monitor it become extremely pain because extremely hard slowly to move windows between screens using title bar.