SUMMARY

I have an 1200x1920 external screen (portrait mode, left) positioned to the left of my laptop screen. When setting some scale factors, then some actions that rely on Kwin knowing which screens touch which other screens - do not work. Examples include:

- using the KWin "Move window left/right" keyboard shortcut to move windows between screens (though the quick tile commands do manage to move windows between screens)
- using arrow keys in the overview to select a window on an adjacent screen

STEPS TO REPRODUCE
1. Set up fractional scaling for the left external screen: kscreen-doctor output.2.scale.0.9
2. Move right screen so that it is in the left most position that doesn't intrude into the left screen: kscreen-doctor output.1.position.1334,720
2. Assign shortcuts to Kwin's "move window left" and "move window right" actions.
3. Try to use keyboard to move one window into the other screen.

OBSERVED RESULT
The window gets stuck at the border between windows and will not move further

EXPECTED RESULT
The window should move to the next screen

SOFTWARE/OS VERSIONS
Operating System: KDE neon Testing Edition
KDE Plasma Version: 6.1.3
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.0
Kernel Version: 6.5.0-41-generic (64-bit)
Graphics Platform: Wayland
Processors: 20 × 12th Gen Intel® Core™ i7-12700H
Memory: 31.0 GiB of RAM
Graphics Processor: Mesa Intel® Graphics

ADDITIONAL INFORMATION
The problem is that the screen position must be an integer number, but the width of an 1200 pixels wide screen scaled to 0.9 is 1200/0.9 = 1333.33... If I set the next screen's position at 1333 it will intrude into the left screen, causing windows, panels and wallpapers to overlap. If I set the next screen's position at 1334, windows will not move past the 0.6 pixels gap between screens. I'm currently using a 0.8 scale factor (which works as 1200/0.8=1500) but that is a bit small for me.

With a 1080 screen this should probably work well with 1080/0.9 = 1200 and 1080/0.8 = 1350.

I tried to work out a few different less than 1 scale factors, and it looks like if the sub-pixel gap is 0.5 pixels or less - then there is no problem. So some kind of floating point rounding is going on? If its currently using the (often default) half-up rounding, then maybe it should be changed to just rounding up?