SUMMARY After updating to Plasma 5.26, when I maximize xwayland apps (e.g. VLC, PyCharm, etc.), a column of 1 or 2 pixels are left to the right showing the background. In some situations it can be unnoticeable, but others can be very distracting. STEPS TO REPRODUCE 1. In order to make it more obvious, choose a bright wallpaper (a solid white wallpaper is perfect) 2. Open a xwayland app (e.g. VLC) and maximize, either with the keyboard or with the window button 3. Observe a column of few pixels on the right not covered by the app OBSERVED RESULT xwayland apps don't use exactly the full screen when maximized. I cannot take a screenshot to show this, because Spectacle seems to ignore that extra column of pixels. EXPECTED RESULT Maximized apps, both xwayland and native wayland ones, should cover all screen when maximized. 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-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 8 × 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics Manufacturer: LENOVO Product Name: 20XYCTO1WW System Version: ThinkPad X1 Yoga Gen 6
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
Created attachment 154145 [details] Still an issue on 5.26.4 5.26.4 seem to have MR 3008. Even applying MR 3215 on top of it, maximized/fullscreen Xwayland windows still get a very noticeable bottom+right border which bleeds the wallpaper. This is with a 2560x1600 px screen with 150% scaling. My main concern is with fullscreen Xwayland games, if this would prevent direct scanout.
(In reply to André M from comment #15) > Created attachment 154145 [details] > Still an issue on 5.26.4 > > 5.26.4 seem to have MR 3008. Even applying MR 3215 on top of it, > maximized/fullscreen Xwayland windows still get a very noticeable > bottom+right border which bleeds the wallpaper. This is with a 2560x1600 px > screen with 150% scaling. My main concern is with fullscreen Xwayland games, > if this would prevent direct scanout. The issues says "fixed in 5.27". Maybe there are some other things in 5.27 that make it work? Have you tested on 5.27 yet?
Well, MR 3215 marked this Bug as closed, but it doesn't fix the issue for me neither. I don't think anything else was merged in 5.27 regarding this issue. I will change the status again and try again when the beta is available.
The fix described in Comment 14 was *only* merged for 5.27. If you're still experiencing it in 5.26.4, it's because you don't have 5.27 yet.
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. ***
I can observe this sometimes on a different laptop with a 2k screen and a scale of 175%. But unfortunately I can't reproduce consistently. Operating System: Arch Linux KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.7-arch1-2 (64-bit) Graphics Platform: Wayland Processors: 22 × Intel® Core™ Ultra 7 155H Memory: 31.0 GiB of RAM Graphics Processor: Mesa Intel® Arc Manufacturer: LENOVO Product Name: 21KDS00600 System Version: ThinkPad X1 Carbon Gen 12
Created attachment 169357 [details] Plasma 6.0.4 + Krita I can reproduce this reliably on my systems using Krita against the panel, other apps it can be hit or miss if the effect will happen to the right side with no panel. Operating System: openSUSE Tumbleweed 20240508 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.8-1-default (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 9 7940HS w/ Radeon 780M Graphics Memory: 90.2 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: Framework Product Name: Laptop 16 (AMD Ryzen 7040 Series) System Version: AJ
Reminds me of Bug 480171, which affects native Wayland windows too. Is there anyone here who's affected and using a scale factor of 100%, 200%, or 300%? If not, perhaps both are actually just the same issue, which in the case of Bug 480171 has been traced to faulty assumptions in the fractional-scale-v1 Wayland protocol.
I hit the same bug on Wayland windows as well: I can reproduce it in Firefox & MPV. With the screen size of 2560x1600, I have a 1px gap on the right and on the bottom side of the display, with 160%, the gap disappears.
Is there anyone here who's affected and using a scale factor of 100%, 200%, or 300%? Anyone?
(In reply to Intergalactic Narwhal from comment #68) > I hit the same bug on Wayland windows as well: I can reproduce it in Firefox > & MPV. With the screen size of 2560x1600, I have a 1px gap on the right and > on the bottom side of the display, with 160%, the gap disappears. Are you sure you are running Firefox in an XWayland window? It received native Wayland support recently. If you're using it in Wayland mode, maybe your comment belongs to 480171.
(In reply to Andrea Ippolito from comment #70) > (In reply to Intergalactic Narwhal from comment #68) > > I hit the same bug on Wayland windows as well: I can reproduce it in Firefox > > & MPV. With the screen size of 2560x1600, I have a 1px gap on the right and > > on the bottom side of the display, with 160%, the gap disappears. > > Are you sure you are running Firefox in an XWayland window? > > It received native Wayland support recently. If you're using it in Wayland > mode, maybe your comment belongs to 480171. oh, nevermind, you mentioned "Wayland windows as well", forgive me for not catching that and forget what I said
(In reply to Nate Graham from comment #69) > Is there anyone here who's affected and using a scale factor of 100%, 200%, > or 300%? Anyone? Hi Nate, using Krita as advised in another comment, I could NOT reproduce with 100 or 200%, but I could with fractional values. Hope this helps. Operating System: openSUSE Tumbleweed 20240606 KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.9.3-1-default (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 7840U w/ Radeon 780M Graphics Memory: 30,7 GiB of RAM Graphics Processor: AMD Radeon 780M Manufacturer: Framework Product Name: Laptop 13 (AMD Ryzen 7040Series) System Version: A7
Created attachment 170241 [details] plasma 6.0.5 + krita pixel gap on the right @ 125%
Created attachment 170242 [details] plasma 6.0.5 + krita NO pixel gaps @ 200%
I'm 90% sure they're the same thing, then--or at least, both need the same in fix in the form of an update to the fractional scaling protocol and then a KWin change to adapt to that. Marking as a duplicate of Bug 480171. Let me know if I'm wrong about this though, Xaver, Vlad, or David. *** This bug has been marked as a duplicate of bug 480171 ***
Well, this is the older one, maybe it's more correct to use this one as the master bug.
*** Bug 480171 has been marked as a duplicate of this bug. ***
I've found that setting a scale factor which divides exactly my native resolution helps with this. On my 2560x1600 screen, I've been using 1.6, even if something closer to 1.45 would fit better for me.
Will be fixed by https://invent.kde.org/plasma/kwin/-/merge_requests/3170, which can go in after the required protocol changes are implemented upstream.
X11 windows don't use any fractional scaling protocols, this is a separate bug that can only be fixed by changes in KWin's X11 handling. The other two bugs will both be fixed by fractional-scale-v2 though
Got it, thanks.
Created attachment 171598 [details] 6.1.2 125% - Chrome (XWayland) has gap whereas Dolphin (wayland) does not. Both tiled.
(In reply to Duy Truong from comment #82) > Created attachment 171598 [details] > 6.1.2 125% - Chrome (XWayland) has gap whereas Dolphin (wayland) does not. > Both tiled. this is a chromium regression unrelated to kwin (happens on all DEs). still not fully fixed yet in latest stable https://issues.chromium.org/issues/347038254
The Xwayland specific issue seems to be gone after some X11 geometry refactors; maximized windows are always properly aligned to the screen in my testing on git master. Quick tiled windows are still affected, but that's a more general issue and is already tracked in bug 480171.
On current git master, the issues with
*** Bug 491153 has been marked as a duplicate of this bug. ***
This is a manifestation of Bug 480171, which is tricky to fix. *** This bug has been marked as a duplicate of bug 480171 ***
Wellllllll that's not what I meant to do. Sorry folks.
Was about to celebrate.. oops =)
Well, this one is still fixed in 6.2.0. ;)