| Summary: | Certain fractional scaling levels cause mouse to stick at screen edge independent of edge barrier feature | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Sam <samuel.collins> |
| Component: | multi-screen | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | fanzhuyifan, karolbe, nate, samuel.collins, xaver.hugl, zacharytalis |
| Priority: | NOR | Keywords: | multiscreen |
| Version: | 6.1.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Sam
2024-07-03 08:03:13 UTC
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. |