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.