Maximized windows have an unrendered 1 pixel gap topmost row. Probably caused by the outline patches.
Can reproduce. We should probably not draw the outline for maximized or tiled windows--at least not for window edges that touch a screen edge. Thankfully it's just a visual gap, not an *actual* gap.
*** Bug 461537 has been marked as a duplicate of this bug. ***
I think I know how to fix this bug, but I have hard time testing it. I do not know how to enable the edited Breeze decoration on my machine. The earlier iterations I did was through this command: dbus-run-session kwin_wayland ~/Repositories/kde/usr/bin/systemsettings This is why I've also missed the bug.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/breeze/-/merge_requests/268
Git commit fbe608b1cd11e1b609f0f251c4d6e494cc52a5d0 by Nate Graham, on behalf of Akseli Lahtinen. Committed on 18/11/2022 at 21:20. Pushed by ngraham into branch 'master'. Fix maximized window gap This should fix the coordinates when windows are maximized, so it doesn't add an extra margin, which is used by the outlines. Since outlines are not drawn when windows are maximized, the area would stay blank. FIXED-IN: 5.27 M +4 -1 kdecoration/breezedecoration.cpp https://invent.kde.org/plasma/breeze/commit/fbe608b1cd11e1b609f0f251c4d6e494cc52a5d0
The latest update for kwin from today appear to have solved the issue for me.
(In reply to Oded Arbel from comment #6) > The latest update for kwin from today appear to have solved the issue for me. My comment was premature - with the current kwin-wayland package from Neon unstable - 4:5.26.3+p22.04+tunstable+git20221124.0014-0 - there's still 1 pixel gap at the top of maximized windows. It does not appear to be really transparent - it shows the top row from the wallpaper but if the wallpaper changes, the top line of the window remains the same, until I move the window or change virtual desktop, at which points when I get back to the maximized window - the top row now looks like the new top row from the wallpaper.
Are you on X11 with scaling? If so this is likely a different issue, so please try on Wayland.
(In reply to Nate Graham from comment #8) > Are you on X11 with scaling? If so this is likely a different issue, so > please try on Wayland. As noted above, I'm using kwin-wayland, and it is set to 100% scaling.
Oh, I see the problem: > current kwin-wayland package from Neon unstable - 4:5.26.3+p22.04+tunstable+git20221124.0014-0 This means you're not using Neon Unstable, but rather it's Neon Testing. You're using the unstable version of the 5.26 package, not the unstable version of the 5.27 package. But the fix is only in 5.27.
(In reply to Nate Graham from comment #10) > This means you're not using Neon Unstable, but rather it's Neon Testing. > You're using the unstable version of the 5.26 package, not the unstable > version of the 5.27 package. But the fix is only in 5.27. I definitely have the repo set to "unstable": $ apt policy kwin-wayland kwin-wayland: Installed: 4:5.26.3+p22.04+tunstable+git20221124.0014-0 Candidate: 4:5.26.4+p22.04+tunstable+git20221129.1426-0 Version table: 4:5.26.4+p22.04+tunstable+git20221129.1426-0 500 500 http://archive.neon.kde.org/unstable jammy/main amd64 Packages 4:5.26.3+p22.04+tunstable+git20221129.1204-0 500 500 http://archive.neon.kde.org/unstable jammy/main amd64 Packages *** 4:5.26.3+p22.04+tunstable+git20221124.0014-0 500 500 http://archive.neon.kde.org/unstable jammy/main amd64 Packages 100 /var/lib/dpkg/status Where the current most up to date kwin-wayland package is 4:5.26.4+p22.04+tunstable+git20221129.1426-0 - which I verified against http://archive.neon.kde.org/unstable/pool/main/k/kwin/ (I do need to update again today). I wasn't really aware of "testing", but looking at it (I'm assuming, at http://archive.neon.kde.org/testing/pool/main/k/kwin/) I can also see just 5.26.4. I also saw "experimental", which is currently at 5.26.3, and at the CI server - no where could I find a 5.27 build...
> I definitely have the repo set to "unstable": I know, but "Neon Unstable" is the marketing name for an OS that ships packages from the git master branch, which is clearly not what you're using since you have packages from the git stable branch. The OS that implements that is called "Neon testing". Regardless, the fix is in the packages for Plasma 5.27, so if you're using the packages for 5.26.something, you won't have it yet.
(In reply to Nate Graham from comment #12) > Regardless, the fix is in the packages for Plasma 5.27, so if you're using > the packages for 5.26.something, you won't have it yet. Apologies for the bug spam on this reportedly fixed issue, but I'm still having problems trying to verify the fix, even though I believe I'm running the correct build, that should include fbe608b1cd11e1b609f0f251c4d6e494cc52a5d0: ---8<--- $ kwin_wayland -v kwin 5.26.80 ---8<--- AFAIK, 5.26.80 is the pre-release version for 5.27.0, so the version I'm running is what will be packaged as 5.27 on release and should already contain the fix. Does that seem reasonable? In regards to the previous conversion (after which my configuration has not changed, but I did run some updates from the http://archive.neon.kde.org/unstable repository), I think there's an issue with the Neon CI - I've looked at https://build.neon.kde.org/view/3%20unstable%20%E2%98%A3%20git%20master/job/jammy_unstable_kde_kwin/ - which is clearly labeled as "unstable git master" and that is currently building Neon packages with the version specification of 5.26.4, even though the logs show it is pulling from git master. Looking at https://invent.kde.org/neon/kde/kwin/-/blob/Neon/unstable/debian/changelog , I can see that "Neon CI" (I assume its the CI bot) recently "released" 5.26.4. On my system it looks like this: ---8<--- $ TZ=utc ls -g --time-style=long-iso /usr/bin/kwin_wayland -rwxr-xr-x 1 root 1702304 2022-12-01 01:02 /usr/bin/kwin_wayland $ dpkg -l kwin-wayland # ... ii kwin-wayland 4:5.26.4+p22.04+tunstable+git20221201.0102-0 amd64 KDE window manager, wayland version, PREVIEW release $ kwin_wayland -v kwin 5.26.80 ---8<--- Unfortunately, this is not the first time I've seen such package version mishaps on Neon CI, and I don't expect this to be the last. Maybe that should be taken care of as part of as the Automation & Systematization goal?
Seems like an issue for the Neon folks!
Created attachment 154454 [details] Screenshots showing the problem still exists The problem is still apparent when running Breeze from 5f58691d7454538c09ca81590d95ec26fbe19d6f (which should include the fix that was at fbe608b1cd11e1b609f0f251c4d6e494cc52a5d0 - at least according to https://invent.kde.org/plasma/breeze/-/commits/master). The screenshot shows 2 crops of the top left corner of dolphin on the same screen - on the left it is "quick tiled top" and on the right side it is maximized. It can be clearly seen that the right side there's a 1 pixel gap at the top that shows the desktop background (which is mostly orange-yellow), and a few more pixels in the corner. This is on Wayland.
Git commit dc404b0c00930d72487ad2fe5745677b8eec3d1f by Nate Graham, on behalf of Akseli Lahtinen. Committed on 20/01/2023 at 15:16. Pushed by ngraham into branch 'master'. kdecoration: Fix outline gap with fractional scale There was some old code lying around from when there was only one outline which was on top of titlebar. This removes all that, which fixes the bug. FIXED-IN: 5.27 M +3 -7 kdecoration/breezedecoration.cpp https://invent.kde.org/plasma/breeze/commit/dc404b0c00930d72487ad2fe5745677b8eec3d1f
Git commit f57c08f13c9fadebea866ff40a27ebdc6c613bd3 by Nate Graham, on behalf of Akseli Lahtinen. Committed on 20/01/2023 at 15:17. Pushed by ngraham into branch 'cherry-pick-dc404b0c'. kdecoration: Fix outline gap with fractional scale There was some old code lying around from when there was only one outline which was on top of titlebar. This removes all that, which fixes the bug. FIXED-IN: 5.27 (cherry picked from commit dc404b0c00930d72487ad2fe5745677b8eec3d1f) M +3 -7 kdecoration/breezedecoration.cpp https://invent.kde.org/plasma/breeze/commit/f57c08f13c9fadebea866ff40a27ebdc6c613bd3
I can confirm that with the current unstable kwin build I can no longer experience the issue.