Bug 459373

This happens to me as well on my HiDPI laptop, it is very noticeable in Blender (with xwayland) as it leaves a 2 pixel gap between the right side and along the bottom of the window, when it is maximized.
It is also noticeable in VLC.

In Blender, most of the app looks very crisp and nice thanks to using its own scaling, but near the right side and bottom, elements are slightly blurry. I wonder if it's because of this gap?

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.25.90
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Kernel Version: 5.19.9-zen1-1-zen
Graphics Platform: Wayland

Laptop: Lenovo IdeaPad 5 Pro 16ACH6
Processor and Graphics: AMD Ryzen 5 5600H with Vega 7 graphics
Product Name: 82L5
System Version: ThinkPad X1 Yoga Gen 6
Screen resolution: 2560x1600
PPI: 188.68
Scaling in Plasma settings: 150%

I also note that same happens in the bottom as confirmed by Aurora.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/3008

Why was the fix not merge to 5.26?

It hasn't been merged anywhere yet; the change is still under review.

*** Bug 458481 has been marked as a duplicate of this bug. ***

Git commit ceae7175006c9b56acc63d40bcaa93986ed28572 by Xaver Hugl.
Committed on 23/10/2022 at 20:06.
Pushed by zamundaaa into branch 'master'.

output: don't round geometry as often

M  +5    -0    src/core/output.cpp
M  +5    -0    src/core/output.h
M  +4    -4    src/wayland/xdgoutput_v1_interface.cpp
M  +4    -4    src/workspace.cpp

https://invent.kde.org/plasma/kwin/commit/ceae7175006c9b56acc63d40bcaa93986ed28572

Git commit dadf93f87ae338d9b3765507d3fd1b3e8c9fa440 by Xaver Hugl.
Committed on 23/10/2022 at 22:36.
Pushed by zamundaaa into branch 'Plasma/5.26'.

output: don't round geometry as often
(cherry picked from commit ceae7175006c9b56acc63d40bcaa93986ed28572)

M  +5    -0    src/core/output.cpp
M  +5    -0    src/core/output.h
M  +11   -11   src/wayland/xdgoutput_v1_interface.cpp
M  +4    -4    src/wayland/xdgoutput_v1_interface.h
M  +2    -2    src/waylandoutput.cpp
M  +4    -4    src/workspace.cpp

https://invent.kde.org/plasma/kwin/commit/dadf93f87ae338d9b3765507d3fd1b3e8c9fa440

The merged patch is only a partial solution for this bug. There are still combinations of screen resolutions and scale factors where one can get a border. Should we keep this open not to forget or should I open a new bug?

(In reply to Iyán Méndez Veiga from comment #9)
> The merged patch is only a partial solution for this bug. There are still
> combinations of screen resolutions and scale factors where one can get a
> border. Should we keep this open not to forget or should I open a new bug?

Maybe so, that makes sense. I have still experienced a small gap on the bottom of Xwayland windows.

I just noticed today that this is again as bad as when I first reported this bug. Was something reverted in 5.26.3?

Yes, part of had to be reverted due to the Xorg session breaking really badly

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/3215

Git commit df77fcd9e01d8cd2a31f785acde214f2146c04e2 by Aleix Pol Gonzalez, on behalf of Aleix Pol.
Committed on 21/11/2022 at 14:16.
Pushed by apol into branch 'master'.

x11window: Calculate the native floor from the begining of the output

If this function is useful to make sure we are properly aligned with the
output's pixels, we should start with the output's 0, otherwise we'll be
carrying over the rounding errors increasingly as our workspace grows.

M  +10   -0    src/core/output.cpp
M  +10   -0    src/core/output.h
M  +9    -4    src/utils/xcbutils.cpp
M  +0    -1    src/utils/xcbutils.h

https://invent.kde.org/plasma/kwin/commit/df77fcd9e01d8cd2a31f785acde214f2146c04e2

Nate: I know the patch was not merged for 5.26.4, but I just compiled kwin 5.26.4 with that additional patch (I guess André M did the same), and it doesn't fix the issue. As far as I know, that commit was the only one mentioned this bug in master.

Created attachment 154154 [details]
Still an issue on kwin-git a93ccbd7e74

Ok, compiled kwin-git, kdecoration-git and kwayland-git as of today, and the issue is still present, but has improved; if you compare with the previous screenshot with VLC, the bottom pixel is gone, and when in fullscreen, Xwayland apps also don't show the bug; BUT when Xwayland app is maximized, on the right side the wallpaper still can be seen; while it's maximized, editing the left panel's width makes it disappear, but as soon as unmaximizing and remaximizing the app, the bleeding shows up again.

Ok, thanks for testing so extensively!

I still observe this issue with Plasma 5.26.90 and KDE Frameworks 5.102.0.

*** Bug 462906 has been marked as a duplicate of this bug. ***

The situation seems to have improved on Plasma 5.26.90 (5.27 beta):
While moving a *xwayland window* between 2 monitors (main 2560x1600 150% with left, top panels; right 2560x1440 135% no panels), when they go to the other monitor while already maximized, they occupy the correct area on the other monitor, leaving no gaps; when unmaximizing and re-maximizing in place, the right border still leaves a couple of pixels off, showing the wallpaper or window below, as before. Either way, bottom gap is gone.

Hi guys. I would highly recommend to add this issue to the "15 minute bug initiative" https://tinyurl.com/plasma-15-minute-bugs.
I am using Plasma (Wayland) with these pixel bugs now for several months and it is not fixed at all, contrary to some comments here. Only on some configurations of monitor placement, resolutions and (important!) scaling the border disappears. But one should not have to worry to set the scaling smaller or bigger than wanted, just to prevent this ugly visual problem, which makes Plasma look buggy from the very first minute of usage where you configure your screens. Also it is a major selling point of Wayland, that now scaling works correctly, important for newer Hi-DPI monitors. This would contradict, at least for KDE Plasma.

Unfortunately I am not a C++ developer myself to provide a fix myself, but I can provide testing data. Here are my findings:
-  I am testing with the program glxgears which provides a black background and runs in Xwayland. Then I set my desktop background to full white. That way one can see the pixel rows better.
- I am using a triple monitor setup with (from left to right): A: 2560x1440@150%, B: 3840x2160@200%, C: 2560x1440@150%
- I am using the newest release plasma-wayland-session 5.27.1-1 on Arch
- By chaning the scaling of the monitors A, B and C I can produce three different states on all of them:
1) No borders at all (perfect)
2) Vertical pixel row on the right spanning up even to the header bar of the window with the size of 1 pixel
3) Number 2 + Horizontal pixel row on the bottom with the size of 1 or 2 pixels

Thanks for your work in this. I hope we can get a real fix soon to make the pixel border a thing of the past, regardless of monitor placement, resolutions and scaling settings. If you need more information don't hesitate to ask.

The 15-minute bug initiative currently doesn't include Wayland-only bugs due to Wayland not being the default session type in Plasma itself.

Hopefully it will get fixed soon, yeah.

Not fixed by the fix for Bug 465850, in case anyone was wondering.

I have a panel on the left screen edge. When an XWayland window is already maximized, changing the panel width or changing the scale factor a little bit (e.g. 175 to 170 or 180 and vice versa) makes gaps disappear. But they come back after re-maximizing the window.

The problem exists now for over 6 months and it does not seem to have improved. Unfortunately I do not have enough insight to provide a fix myself. Could anyone involved in KWin please take a look at this problem? I think it influences the whole Plasma experience on Wayland as nearly anyone uses some kind of legacy application with xWayland and Hi-DPI monitors with scaling get more and more common. Who knows, maybe it is just a "off by one error" somewhere in the forwarding of the coordinates from the Xorg application to the Wayland wrapper window in KWin. Or the coordinates returned when the maximizeWindow() function is called returns wrong values, explaining why the border sometimes disappears until one maximizes the window again. Whatever it is, please try to find a solution. Thanks to all involved.

*** Bug 467658 has been marked as a duplicate of this bug. ***

*** Bug 468131 has been marked as a duplicate of this bug. ***

A weird behavior (probably related) that maybe helps debug this. When running Inkscape with Xyayland (with native wayland it crashes continuously for me at the moment), if one maximizes the window and start working with the app (just by moving the mouse around, for example), the window starts to get resized, reducing the height. I will attach a video later today since this is hard to explain with words.

*** Bug 469122 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4088

Git commit a48c98f5aba71fab8bc1e1d5dd18668833631920 by Xaver Hugl.
Committed on 10/05/2023 at 10:52.
Pushed by zamundaaa into branch 'master'.

xcbutils: fix nativeFloor

The floor was not done in the X-native coordinate space but with double
scaling

M  +1    -1    src/utils/xcbutils.cpp

https://invent.kde.org/plasma/kwin/commit/a48c98f5aba71fab8bc1e1d5dd18668833631920

THANK YOU Xaver!!! I confirm the patch works for me.

Too bad it didn't make it to 5.27.5. Hopefully, some distros will pick the one line patch.

As a side comment, I've seen several similar issues in the last months (I think since Plasma 5.25). Maybe is it possible to include some unit tests for the different scaling cases? Probably it fits the "Automate And Systematize Internal Processes" goal, no? The thing is that these issues are hard to debug, but very noticeable by affected users. Maybe for Plasma 6.0?

Git commit 2237391e979b2423462bb5eaf1fdf4c0876f7476 by Vlad Zahorodnii, on behalf of Xaver Hugl.
Committed on 10/05/2023 at 11:11.
Pushed by vladz into branch 'Plasma/5.27'.

xcbutils: fix nativeFloor

The floor was not done in the X-native coordinate space but with double
scaling


(cherry picked from commit a48c98f5aba71fab8bc1e1d5dd18668833631920)

M  +1    -1    src/utils/xcbutils.cpp

https://invent.kde.org/plasma/kwin/commit/2237391e979b2423462bb5eaf1fdf4c0876f7476

Sorry to finish the "it's fixed" party, but after double checking on my laptop, I still get a 1px gap down (but not on the right). Is it possible that there is another similar issue affecting the vertical size?

Yes, there is at least one known additional issue, which will (usually) only be between the panel and the window. Please create a separate bug report for that, with the resolution + scale + if it happens with Wayland native windows too

(In reply to Zamundaaa from comment #41)
> Yes, there is at least one known additional issue, which will (usually) only
> be between the panel and the window. Please create a separate bug report for
> that, with the resolution + scale + if it happens with Wayland native
> windows too

Yes, exactly, it's only between the panel and the window, but ONLY XWayland apps, not Wayland native windows. Should I open a new issue or can we keep this one open?

Created attachment 158837 [details]
Still an issue

I think this is not fixed, got the issue with this patch applied on top of 5.27.5, with the pixel NOT between the window and panel (attached screenshot). 2560x1600@145% window (there's a 2560x1440@135% screen to the right, but it shouldn't matter, right?), VLC flatpak on Xwayland.

Just to remark: if the Xwayland window is in maximized state, and *moved* to another screen (e.g. through Meta+Shift+Left/Right or Present Desktops effect), when it lands on the other screen, it doesn't have the gap. Unmaximizing and remaximizing makes the gap show off. So it looks like the Maximized Geometry calc when moving screens is correct, and the restore/remaximize one is wrong.

I just noticed another behavior. When maximizing a Xwayland application and then closing and reopening it, it is not maximized anymore and has a 5 pixel border on the right. This happens f.e. with Spotify (Electron).

This is still happening to me when using:

•  LibreOffice: https://i.imgur.com/kI3ytcF.png
• Gwenview: https://i.imgur.com/uA62KvI.png
• Dolphin: https://i.imgur.com/gOStT09.png
• System settings: https://i.imgur.com/b1vTYVM.png (this screenshot shows the resolution of my screen, just in case this helps)
• Other software like Kdenlive, KDevelop, Kate...

Doesn't happen on Firefox or GIMP.

This happens both when I maximize the windows, and they get opened maximized already.

This is all on X11.  None of this happens on Wayland.
I'm using Arch Linux, with Plasma 5.27.6. Intel graphics (Alder Lake-P Integrated Graphics Controller) on a Lenovo Yoga slim 7i pro (with high DPI).

*** Bug 471832 has been marked as a duplicate of this bug. ***

Created attachment 160207 [details]
Spotify

Still happens with Spotify on 5.27.6.

i can confirm the bug is still present
some observations i have found:
- snapping the window to a corner or edge does not result in gaps
- resizing the window to take up the whole screen does not show gaps
- only maximizing the window results in the gaps
- resizing the panel to any value while the window is maximized removes the gaps

Can anyone reproduce the bug in 5.27.8? A fix landed in Breeze to fix the 1px gap on X11, but I am not sure if it's the same bug.

https://invent.kde.org/plasma/breeze/-/merge_requests/352

Didn't have time to check X11, but I just updated on my laptop and rebooted, can still observe on 5.27.8

Thanks

No, no difference for me neither with Plasma 5.27.8.

*** Bug 474843 has been marked as a duplicate of this bug. ***

5.27.10, still reproducible

Still reproducible for me in Plasma 6, too.

Reproducible when using only wayland native apps on Plasma 6 RC2 with Qt 6.7.0 (archlinux). Weirdly what fixes it right away is swiping 3 fingers right (with no virtual desktop change since there isn't one on the left).

That sounds like something else, maybe Bug 480171.

*** Bug 481097 has been marked as a duplicate of this bug. ***

I also see this happening in Plasma 6rc2, not only with XWayland, but also native Wayland apps.
I added some logs to xdgshellwindow.cpp, and it seems the events emit QRectFs in translated coordinates, e.g.: if you have 1200p screen with 1.45x scale, it'll send a client height of 827.5862p. Eventually, this won't add up and the gaps will show.
How feasible it'd be to keep physical/real dimensions everywhere (since those are always integers), and have the scale be sent to the clients just as a hint to render larger elements? i.e. move scale to the "edges" of the software

For native Wayland apps see bug 480171; its cause is the Wayland protocol for fractional scaling being inherently broken.

Git commit 2491fb1b2b02db5352bc02050298e7522d4dfaa5 by Vlad Zahorodnii.
Committed on 01/03/2024 at 14:50.
Pushed by vladz into branch 'master'.

Ignore size hints when maximizing X11 windows

This is to help to fix maximized xwayland windows not covering the whole
work area. Size hints are obeyed only when restoring the window.

According to the net wm spec, the window manager should not obey size
hints when maximizing a window and some other window managers already ignore
them when maximizing windows.

M  +15   -92   src/x11window.cpp

https://invent.kde.org/plasma/kwin/-/commit/2491fb1b2b02db5352bc02050298e7522d4dfaa5

*** Bug 482368 has been marked as a duplicate of this bug. ***

*** Bug 484700 has been marked as a duplicate of this bug. ***